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ABSTRACT 


This  report  presents  the  final  results  of  work  performed  by  ARINC 
Research  Corporation  under  Contract  F09603-80-G-3338-0011  with  Warner 
Robins  Air  Logistics  Center /MMRRAH.  ARINC  Research  was  tasked  to  perform 
a  long-range  study  of  the  functional  and  system  requirements  of  the 
Electronic  Warfare  Avionics  Integration  Support  Facility  (EWAISF)  support 
processor.  This  document  describes  the  results  of  the  four  phases  of 
that  effort:  the  definition  of  functional  requirements,  specification  of 
requirements  for  automatic  data  processing  equipment  (ADPE)  and  software, 
identification  of  alternative  architectures  to  fulfill  these  requirements, 
and  a  cost-benefit  analysis  of  the  alternatives.  In  addition,  it  presents 
recommendations  for  implementing  a  preferred  architecture  and  describes  a 
means  for  updating  the  study  in  the  event  that  requirements  or  operational 
constraints  should  change. 


ABSTRACT  .  v 

CHAPTER  ONE:  BACKGROUND  .  1-1 

CHAPTER  TWO:  PROJECT  OBJECTIVES  .  2-1 

CHAPTER  THREE:  PROJECT  APPROACH  .  3-1 

3.1  Overview . 3-1 

3.2  Phase  1  -  Functional  Analysis .  3-2 

3.3  Phase  2  -  Requirements  Analysis .  3-4 


3.3.1  Definition  Leveling  .  3-4 

3.3.2  Setting  Requirements  Priorities  .  3-4 

3.3.3  Requirements  Validation  .  3-4 

3.4  Phase  3  -  Alternatives  Definition  .  3-5 

3.5  Phase  4  -  Cost-Benefit  Analysis .  3-5 

CHAPTER  FOUR:  EWAISF  SUPPORT  REQUIREMENTS  .  4-1 

4.1  Functional  Analysis  Results .  4-1 

4.1.1  Application  Requirements  .  4-1 

4.1.2  Support  Processor  Requirements  .  4-8 

4.2  Requirements  Analysis  Results  .  4-9 

4.2.1  Composite  Requirements  .  4-10 

4.2.2  Setting  Requirements  Priorities  .  4-10 

4.2.3  Requirements  Validation  .  4-10 

4.2.4  ADPE  and  Software  Requirements .  4-19 

CHAPTER  FIVE:  ALTERNATIVE  SUPPORT  ARCHITECTURES  .  5-1 

5.1  Single-Processor  Architecture  .  5-2 

5.1.1  Concept .  5-2 

5.1.2  System  Components  .  5-3 

5.2  Multiple-Processor  Architecture .  5-6 

5.2.1  Concept .  5-6 

5.2.2  System  Components  .  5-8 


Vll 


US  >  •  ■* 


CONTENTS  (continued) 


Page 

5.3  Front-End  Processor  Architecture  .  5-9 

5.3.1  Concept .  5-9 

5.3.2  System  Components  .  5-10 

5.4  Summary .  5-13 

CHAPTER  SIX:  COST-BENEFIT  ANALYSIS  .  6-1 

6.1  Methodology .  6-1 

6.2  Architectural  Alternatives  .  6-1 

6.3  Cost  Estimation .  6-2 

6.3.1  Development .  6-4 

6.3.2  Investment .  6-4 

6.3.3  Operation .  6-5 

6.3.4  Composite  Life-Cycle-Cost  Estimates  .  6-7 

6.4  Benefits  Estimation  .  6-7 

6.4.1  System  Performance  as  System  Benefit  .  6-7 

6.4.2  Strategy  for  Estimating  Performance  .  6-7 

6.4.3  Comparative  Simulation  Results  .  6-14 

CHAPTER  SEVEN:  RECOMMENDATIONS  FOR  IMPLEMENTING  THE 

PREFERRED  ALTERNATIVE  .  7-1 

7.1  Overview  of  Approach .  7-1 

7.1.1  Phase  1:  Multiple-Processor  Prototype 

Development .  7-1 

7.1.2  Phase  2:  Initial  Operation  .  7-4 

7.1.3  Phase  3:  Front-End  Processor  Prototype 

Development .  7-4 

7.1.4  Phase  4:  Front-End  Processor  Operation  .  7-5 

7.2  Schedule . . .  7-5 

7.3  Other  Considerations  .  7-7 

APPENDIX  A:  USER  REQUIREMENTS  DEFINITION  .  A-l 

APPENDIX  B:  COMPOSITE  FUNCTIONAL  REQUIREMENTS  .  B-l 

APPENDIX  C:  FINANCIAL  BASIS  FOR  COST  ESTIMATES  .  C-l 


viii 


CONTENTS  (continued) 


APPENDIX  D:  PRICE  QUOTATIONS  .  . 
APPENDIX  E:  PERFORMANCE  SIMULATION 
APPENDIX  F:  STUDY  UPDATE  PROCEDURE 


Page 

D-l 


E-l 


F-l 


ix 


CHAPTER  ONE 


1 


BACKGROUND 


i 


In  1975,  the  Engineering  Division  (MME)  developed  a  data  automation 
requirement  (DAR)  for  an  Electronic  Warfare  Avionics  Integration  Support 
Facility  (EWAISF)  host  computing  capability.  The  DAR  was  developed  in 
response  to  a  need  for  a  host  computing  facility  to  provide  management 
and  computational  support  to  MME.  In  September  1976,  two  excess  computer 
systems  became  available,  an  IBM  360/65  and  a  UNIVAC  1108.  An  evaluation 
was  performed;  the  UNIVAC  1108  was  selected;  and,  in  February  1977,  the 
excess  equipment  was  delivered  to  Robins  Air  Force  Base  (AFB)  from  the 
Global  Weather  Center  ( AFGWC ) ,  Offutt  AFB,  Nebraska.  It  was  anticipated 
early  that  the  processing  requirement  for  the  U1108  would  grow. 

The  need  for  "continuous  acquisition  planning"  was  recognized  in  the 
EWAISF  Host  Computer  Data  Project  Plan  (DPP),  dated  10  March  1977.  That 
plan  documented  the  initial  acquisition  planning  for  the  host  computer 
facility.  Since  the  development  of  the  DPP,  the  anticipated  workload  for 
the  U’ 108  has  increased  due  to  the  expansion  of  the  U1108  user  base  as  well 
as  t  an  expansion  of  the  functions  to  be  performed.  The  functions  cur- 
re:  i.y  supported  by  the  host  computing  facility  were  documented  in  the 
Concept  of  Operation,  EWAISF  Host  Processor,  UNIVAC  1108,  dated  19  Septem¬ 
ber  1980.  This  is  a  working  document  that  evolves  to  reflect  changes  in 
requirements  and  plans.  Utilization  of  the  EWAISF  support  processor  is  a 
direct  function  of  the  number  of  users  and  of  the  electronic  warfare  and 
operational  flight  programs  (EW/OFP)  supported.  Recent  growth  in  U1108 
workload  and  anticipated  expansion  of  processor  functions  and  systems  sup¬ 
ported  have  prompted  the  current  system  manager  (MMRRAH)  to  initiate 
this  study  to  define  support  processor  requirements  for  1985  and  beyond. 
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CHAPTER  TWO 
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PROJECT  OBJECTIVES 


ARINC  Research  Corporation  is  under  contract  with  Warner  Robins  ALC/ 
MMRRAH  to  define  the  EWAISF  support  processor  requirements  for  1985  and 
beyond  and  develop  recommendations  for  satisfying  those  requirements.  The 
output  of  this  effort  should  provide  the  Air  Force  with  adequate  background 
information  for  preparation  of  an  acquisition  justification  for  any  auto¬ 
matic  data  processing  equipment  (ADPE)  or  software  required  by  the  EWAISF 
in  that  time  frame.  The  specific  tasks  required  to  accomplish  these  objec¬ 
tives  are  (1)  definition  of  support  processor  functional  requirements,  (2) 
synthesis  of  ADPE  and  software  requirements,  (3)  development  of  alterna¬ 
tive  approaches,  (4)  economic  analysis  of  alternatives,  and  (5)  selection 
and  documentation  of  a  preferred  alternative.  An  additional  objective  to 
be  achieved  from  this  effort  is  a  method  that  will  allow  MMRRAH  to  update 
the  study  results  as  required  by  unforeseen  changes  in  EWAISF  support 
processor  requirements . 
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CHAPTER  THREE 


PROJECT  APPROACH 


3.1  OVERVIEW 

The  technical  approach  consisted  of  an  orderly,  disciplined  procedure 
of  four  steps: 

•  Defining  EWAISF  support  processor  functional  requirements 

•  Quantifying  system  performance  criteria 

•  Projecting  system  growth 

•  Selecting  the  most  cost-effective  approach  to  satisfying  the 
system  requirements 

The  philosophy  underlying  the  approach  called  for  continuous  user  partici¬ 
pation.  Each  phase  of  the  effort  was  directly  linked  to  the  other  phases, 
ensuring  that  system  requirements  were  complete  and  correct  and  that  the 
recommended  alternative  satisfied  the  requirements  in  a  cost-effective  and 
affordable  manner.  The  effort  consisted  of  four  phases: 

1.  Functional  Analysis  -  Review  of  previous  efforts,  definition  of 
EWAISF  support  processor  functions,  and  development  of  preliminary 
supporting  data  requirements 

2.  Requirements  Analysis  -  Development  of  automatic  data  processing 
performance  requirements  and  setting  priorities  and  selecting 
functional  requirements  for  implementation 

3.  Alternatives  Definition  -  Development  of  alternative  approaches, 
ADP  configurations,  software,  and  procedures  to  satisfy  the 
requirements  as  defined  in  the  requirements  analysis  phase 

4.  Cost-Benefit  Analysis  -  Analysis  of  the  benefits  (quantifiable 
and  nonquantif iable )  to  be  derived  from  each  of  the  alternatives, 
and  estimation  of  the  life-cycle  costs  of  each  alternative 

This  document  presents  the  final  results  of  the  efforts  under  each  of 
the  four  phases  and  the  recommended  approach  for  implementing  the  preferred 
alternative. 


3.2  PHASE  1  -  FUNCTIONAL  ANALYSIS 


The  purpose  of  this  task  was  to  define  the  long-range  functional 
requirements  for  an  EWAISF  support  processor.  The  objective  was  to 
develop  a  baseline  set  of  functions  to  which  performance  criteria  can 
be  attached  and  against  which  alternative  solutions  can  be  hypothesized. 

This  analysis  consisted  of  four  activities: 

•  Review  of  current  definitions  of  requirements 

•  Review  of  previous  analyses 

•  Interviews  of  users 

•  Definition  of  functional  requirements 

The  current  definitions  of  requirements  are  contained  in  the  Concept 
of  Operations  and  in  initial  surveys  previously  conducted  by  MMR  personnel. 
These  sources  were  reviewed  to  familiarize  the  study  team  with  the  EWAISF 
support  processor  applications  environment.  In  addition,  projected  require¬ 
ments  were  summarized  for  some  electronic  warfare  (EW)  systems  in  their 
resource  acquisition  management  plans  (RAMPs) .  Those  RAMPs  available  at 
the  time  of  the  first  phase  were  reviewed  for  background  data.  Two  previous 
analyses  were  reviewed  in  preparation  for  the  first  phase.  The  first  pre¬ 
sented  requirements  for  a  project  control  and  monitoring  system*  and  the 
second  described  the  results  of  a  previous  support  software  study.** 

A  preliminary  survey  of  current  and  potential  support  processor  users 
was  conducted  to  solicit  projected  functional  requirements.  These  users 
included  EW  systems  engineering  and  logistics  management  personnel,  admin¬ 
istrative  and  MMR  division  support  personnel,  and  MMEC  personnel  providing 
operational  flight  program  engineering  or  logistics  management.  The 
requirements  identified  in  the  preliminary  surveys  were  recorded  on 
requirement  specification  forms.  Figure  3-1.  The  user-defined  requirements 
were  then  categorized  and  summarized  for  presentation  herein.  The  forms 
will  provide  an  audit  trail  for  each  identified  requirement  throughout  the 
study. 

The  specification  forms  show  the  requirements  anticipated  by  support 
processor  users  for  1985  and  beyond .  Some  of  these  requirements  are  cur¬ 
rently  supported  by  the  UNIVAC  U1108  system,  but  others  are  not.  For  some, 
the  support  requirements  change  from  the  present  to  the  study  time  frame. 

The  form  is  divided  into  three  general  fields:  descriptive  information, 
current  ADP  support,  and  projected  requirements  for  1985  and  beyond. 


* Interim  Engineering  Report,  System  Requirements  for  Project  Monitoring 
and  Control  System,  TM-HU-400/000/00 ,  System  Development  Corporation, 
August  24,  1976. 

**Electronic  Warfare  Avionics  Integration  Support  Facility  Support  Soft¬ 
ware  Study  -  Final  Report,  TRW  Defense  and  Space  Systems  Group,  December 
1977. 
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ADP  REQUIREMENTS  SPECIFICATIONS 


Figure  3-1.  SAMPLE  ADP  REQUIREMENTS  SPECIFICATIONS  FORM 


The  information  necessary  for  this  phase  of  the  analysis  consisted  of 
the  descriptive  information  to  be  provided  in  the  upper  portion  of  the 
form  and  the  software  functions  portions  of  the  current  support  and  pro¬ 
jected  requirements  sections,  Any  additional  information  supplied  by  the 
respondents  was  included;  if  there  was  none,  the  areas  not  required  were 
left  blank.  The  forms,  as  completed  and  reviewed  by  the  users,  are  included 
in  the  appendix  of  this  report.  The  basis  or  definition  of  responses  varied 
from  user  to  user.  No  attempt  was  made  to  level  these  definitions  in  Phase 
1,  but  this  was  accomplished  in  the  iterative  interview  portion  of  the 
requirements  analysis  phase. 


3.3  PHASE  2  -  REQUIREMENTS  ANALYSIS 

The  first  phase,  Functional  Analysis,  elicited  and  summarized  the 
functional  requirements  of  the  EWAISF  support  processor  from  the  viewpoint 
of  the  individual  users  and  applications.  The  second  phase.  Requirements 
Analysis,  provided  a  leveling  of  the  definitions  of  the  requirements,  set 
priorities  among  the  requirements  by  the  users,  and  provided  a  validation 
of  the  requirements  by  EWAISF  management  personnel. 


3.3.1  Definition  Leveling 

The  first  task  in  Phase  2  was  to  develop  a  composite  set  of  definitions 
for  the  requirements  identified  in  Phase  1.  To  accomplish  this  task,  the 
complete  set  of  Requirements  Specification  Forms  developed  in  Phase  1  was 
circulated  to  the  users  for  review.  This  allowed  them  to  review  their  own 
requirements  and,  in  addition,  provided  them  the  opportunity  to  review 
those  of  other  users.  The  review  stimulated  additional  requirements  and 
led  to  the  refinement  of  those  under  review.  At  the  completion  of  the 
review,  the  responses  were  collected  and  applied  to  the  identified  require¬ 
ments  to  develop  a  composite,  consensus  list  of  functional  requirements 
for  validation. 

3.3.2  Setting  Requirements  Priorities 


Following  the  leveling  process,  the  composite  requirements  definitions 
were  circulated  to  the  users  for  a  final  review.  At  this  time,  the  users 
were  requested  to  rank  the  requirements  in  order  of  their  operational 
priorities.  Mean  and  standard  deviations  of  the  priorities  were  then 
calculated. 


3.3.3  Requirements  Validation 

After  the  priority  survey  was  completed,  the  user  requirements  were 
presented  to  EWAISF  management  personnel  for  validation.  The  requirements 
were  first  presented  to  the  Integrated  Support  Station  (ISS)  Support 
Subcommittee.  The  Subcommittee  reviewed  the  requirements  are  presented 
recommendations  to  the  EWAISF  Committee,  which  validated  a  set  of  functional 
requirements.  This  set  of  requirements  provides  the  basis  for  the  remaining 
phases  of  this  study. 
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3.4  PHASE  3  -  ALTERNATIVES  DEFINITION 


•  • 


The  third  phase  of  the  study.  Alternatives  Definition,  provides  a 
description  of  alternative  architectures  for  fulfilling  the  ADPE  and 
software  requirements  specified  as  a  result  of  Phase  2,  Requirements 
Analysis.  From  an  initial  set  of  candidate  architectures,  three  were 
selected  for  further  evaluation  in  Phase  4,  Cost-Benefit  Analysis.  Low- 
and  high-cost  options  were  specified  for  each  alternative,  corresponding 
to  inclusion  of  the  required  capabilities  (low  cost)  or  the  required  and 
desired  capabilities  (high  cost),  as  identified  in  Phase  2. 

Three  architectures  were  presented  to  the  ISS  Support  Subcommittee  at 
its  regularly  scheduled  June  meeting.  One  of  the  architectures  was  replaced 
with  another  considered  to  be  of  less  technical  risk.  The  computer  vendor 
community  was  then  surveyed  to  assure  that  the  three  candidate  architectures 
could  be  implemented  with  current,  commercially  available  ADPE  and  support 
software.  The  resultant  candidate  architectures  are  described  in  Chapter 
Five. 


3.5  PHASE  4  -  COST-BENEFIT  ANALYSIS 

The  fourth  phase  of  this  effort,  Cost-Benefit  Analysis,  yields  an 
assessment  of  the  relative  cost-effectiveness  of  the  alternatives  defined 
in  Phase  3.  The  cost  estimation  of  the  alternatives  was  relatively  straight¬ 
forward.  The  cost  model  used  in  the  study  was  formulated  and  presented  to 
the  ISS  Support  Subcommittee  for  approval.  Cost  data  were  then  collected 
and  summarized  for  the  10-year  system  life  cycle. 

The  benefits  estimation  was  more  complex.  Three  separate  approaches 
wer  developed:  qualitative  assessment,  panel  scoring,  and  performance 
simulation.  These  alternatives  were  presented  to  the  ISS  Support  Subcom¬ 
mittee,  which  selected  performance  simulation  as  the  technique  to  be  employed. 

The  results  of  the  cost  and  benefits  estimations  were  then  summarized 
and  are  presented  in  Chapter  Six. 


I 

1 

I 


jUif  if  i  i '  rniWfci'Minnr  'nrr-"  -t  i  >  • 


CHAPTER  FOUR 


EWAISF  SUPPORT  REQUIREMENTS 


This  chapter  presents  the  results  of  an  examination  of  the  EWAISF  sup¬ 
port  processor  long-range  requirements  through  the  first  two  phases  — 
Functional  Analysis  and  Requirements  Analysis. 


4.1  FUNCTIONAL  ANALYSIS  RESULTS 

The  results  of  Phase  1,  Functional  Analysis,  are  presented  in  two 
categories:  applications  requirements  and  support  processor  requirements. 
Applications  requirements  are  those  identified  by  EWAISF  support  processor 
users  as  either  required  or  desired  capabilities  in  the  time  frame  to  which 
the  study  applies,  1985  and  beyond.  This  does  not  imply  that  some  of  the 
capabilities  are  not  currently  required,  only  that  they  will  be  required 
in  1985  and  after.  The  requirements  definitions,  as  presented  in  the 
appendix,  were  reviewed  with  the  originators,  where  possible,  to  ensure 
their  accuracy.  They  are  summarized  herein. 

The  support  processor  requirements  are  those  implicit  ones  derived 
from  the  requirements  specified  by  the  users.  They  are  generally  functions 
required  to  satisfy  a  particular  operational  consideration  or  mode,  e.g., 
interactive  inquiry  or  remote  printer  control.  Those  presented  herein 
represent  only  those  derived  from  the  applications  requirements  or  identi¬ 
fied  by  interviewees.  Other  support  processing  requirements  will  evolve 
with  the  development  of  alternative  system  architectures  and  specific 
operating  modes  during  subsequent  study  phases. 

4.1.1  Application  Requirements 

The  application  requirements  specified  by  the  survey  population  fall 
into  four  broad  categories: 

•  System  operational  software  support 

•  Engineering  management  support 

•  Logistics  management  support 

•  Administrative  and  division  management  support 
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System  operational  software  support  includes  those  capabilities  required  to 
support  the  electronic  warfare  (EW) ,  avionics  operational  flight  program 
(OFP) ,  or  emitter  identification  data  (EID)  software  changes,  including 
code  modification,  testing,  and  change  distribution.  Engineering  manage¬ 
ment  support  includes  those  capabilities  required  to  plan,  monitor,  and 
implement  OFP,  EID,  and  support  software  or  hardware  changes.  Logistics 
management  support  includes  capabilities  for  planning,  budgeting,  imple¬ 
menting,  and  monitoring  integrated  logistics  support  elements  for  EW  sys¬ 
tems.  Administrative  and  division  management  support  functions  are  those 
necessary  to  plan  and  control  division  resources  in  the  accomplishment  of 
the  other  functions.  Each  of  these  categories  is  summarized  below. 

4. 1.1.1  System  Operational  Software  Support 

The  system  operational  software  support  requirements  identified  by 
the  interviewees  were  subdivided  into  the  following  classes: 

•  Code  development 

•  Verification  and  validation  (VSV)  and  test 

•  Documentation  maintenance 

•  Change  distribution 

A  general  consensus  existed  among  systems  engineers  that  change  software 
development  support  by  an  EWAISF  support  processor  should  consist  of  pro¬ 
viding  interactive  back-up  capabilities  to  the  system  ISSs  or  avionics  inte¬ 
grated  support  facilities  (AISFs) .  The  specific  functions  described 
included  program  file  maintenance,  code  creation  and  editing,  program 
assembly  and  binding,  and  loading  of  software  to  system  processors.  The 
processors  for  which  these  capabilities  would  be  required  are  listed  in 
Table  4-1.  Program  file  maintenance  was  defined  to  be  a  means  of  trans¬ 
ferring  software  changes  from  the  ISS  edit/assembly  station  to  the  EWAISF 
support  processor  to  maintain  currency  of  the  back-up  files.  Code  develop¬ 
ment  was  defined  to  consist  of  source  file  editing  facilities.  Assembly 
and  binding  refers  to  the  process  of  preparing  executable  programs  from 
assembler-level  source  code.  Loading  of  software  to  system  processors 
varied  somewhat  in  definition  from  preparation  of  binary  tapes  to  direct 
download  over  a  data  link.  No  requirements  for  compilation  of  higher  order 
language  (HOL)  source  programs  were  explicitly  identified.  However,  certain 
identified  requirements  create  an  implicit  requirement  for  compilation  of 
HOLs. 


A  wide  range  of  capabilities  was  identified  as  being  required  to 
support  verification  and  validation  and  system  test.  No  general  consensus 
was  developed  for  any  specific  capability.  Table  4-2  is  a  matrix  relating 
the  capabilities  identified  and  the  offices  or  systems  specifying  the 
requirements.  The  categories  are  fairly  broad,  but  for  the  purposes  of 
this  analysis  have  these  general  definitions: 

•  ECP  Traceability.  This  is  the  capability  to  track  engineering 
change  proposal  (ECP)  requirements  from  specification  to  imple¬ 
mentation  and  to  monitor  V&V  and  test  results  on  the  basis  of 
individual  requirements. 
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Table  4-1 .  SYSTEM  PROCESSORS  TO  BE  SUPPORTED 


System 

Processor 

EF-111  TJS 

IBM  4Pi 

Litton  LC-4516 

AN/AYK-14* 

Teledyne* 

AN/ALR-62 

CM  456 

AN/ALQ-119 

CX2-475-01 

Intel  8085 

Zilog  280 

AN/AL7.-69 

CM  479 

AT AC- 8 

AN/ALR-69  (Update) 

ATAC-16M 

AN/ALQ-1 31 

Westinghouse  Minicomputer 

F-15  TEWS 

TI  2520-2 

Motorola  6800 

AN/ALQ-1 55 

Intel  3001  (emulating  NOVA) 

AN/ALR-46 

CM  442,  442A 

AN/APR-38 

TI  1255 

AN/ALQ-1 2 5 

LC  4516 

AN/ALM-126 

HP9825 

AN/ALQ-165 

ATAC-16M 

IRS 

Intel  8085 

FLTS 

Not  Determined 

AN/ALQ-1 17 

ITT  Microprocessors 

‘Potential  requirement,  not  firm  at  this  point. 

Data  Reduction/Analysis.  This  includes  rehosting  of  existing  soft¬ 
ware  packages  and  provision  of  generalized  data  sorting  and  statis¬ 
tical  analysis  routines.  This  area  provided  the  least  detailed 
requirement  definition  of  the  analysis,  yet  was  one  of  the  more 
widely  requested  capabilities.  This  may  have  been  so  because  a 
number  of  systems  are  just  making  a  transition  or  will  in  the  near 
future,  and  only  two  or  three  systems  (including  F-15  Tactical 
Electronic  Warfare  System  (TEWS)  and  APR-38]  have  any  significant 
experience  in  this  area. 


•  Emulation/Simulation/Modeling.  Emulation  requirements  were  defined 
for  specific  processors  and  as  generalized  emulation  capabilities. 
Simulation  and  modeling  were  divided  into  two  subclasses,  on-line 
environmental  simulations  and  off-line  system  and  software 
simulations. 

•  Threat  Data  Maintenance/Extraction.  This  is  the  ability  to  main¬ 
tain  the  electronic  warfare  integrated  reprogramming  data  base  and 
provide  target  parameters  for  threat  simulator  operations. 

•  Performance/Software  Analysis.  This  is  the  capability  to  analyze 
software  statically  for  syntactic  correctness  or  code  optimization 
and  to  dynamically  collect  execution  data  to  determine  subroutine 
use  and  choke  points. 

Documentation  maintenance  was  consistently  identified  as  a  necessary 
capability,  independent  of  the  system  ISSs.  Two  types  of  documentation 
support  were  identified.  The  first  is  document  production  support,  con¬ 
sisting  of  text  entry  and  editing  capabilities,  page  and  document  formatting, 
and  document  printing.  These  are  typical  word  processing  capabilities.  The 
second  type  of  documentation  support  identified  is  the  automatic  production 
of  computer  software  documentation.  This  typically  consists  of  memory/load 
maps,  cross-reference  lists,  flow  charts  and  module  hierarchies,  and  inter¬ 
face  listings. 

Distribution  of  OFP  and  EID  changes  from  field  reprogramming  has 
generally  been  accomplished  by  mailing  the  changes  on  paper  tape.  Most 
systems  now  require  the  use  of  AUTODIN  for  change  transmissions,  partic¬ 
ularly  for  emergency  changes.  Therefore,  an  EWAISF  support  processor 
should  be  capable  of  producing  AUTODIN-compatible  binary  magnetic  tape  for 
message  transmission.  These  tapes  must  also  be  compatible  with  whatever 
memory  loader/verifier  capability  exists  in  the  field. 

4 . 1 . 1 . 2  Engineering  Management  Support 

A  number  of  capabi 1 i ties  identified  fall  into  the  category  of  support 
to  the  management  of  the  change  process.  These  include  the  following: 

•  Document  control 

•  Project  planninq  and  control 

•  Configuration  management 

•  Software  archive  support 

Document  control  provides  for  the  status  accounting  and  location  of  all 
system-related  documentation.  This  was  identified  as  two  types  of 
requirement  --  documentation  identification  and  location  tracking,  and 
documentation  effoctivity  and  traceability.  Those  systems  or  organiza¬ 
tions  requesting  these  functions  are  shown  in  Table  4-3. 

The  requirements  for  project  planning  and  control  involved  a  fairly 
wide  range  of  capability.  The  defined  capabilities  range  from  simple 
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Table  4-3.  DOCUMENT  CONTROL  REQUIREMENTS 

System  or 
Organization 

Documentation 
Identification 
and  Location 

Document 

Effectivity/ 

Traceability 

AN/ALR-62 

X 

X 

AN/ALQ-119 

X 

EWOLS/ECSAS 

X 

X 

AN/ALR-46 

X 

AN/ALR-69 

AN/ALQ-131 

A 

EF-111A 

X 

F-15  TEWS 

X 

AN/ALQ-155 

X 

AN/APR-38 

X 

AN/APR-125 

X 

GPS 

X 

Software  Tools  Group 

X 

tabular  or  printer  graphics  display  of  milestone  schedules  to  network  anal¬ 
ysis  of  schedule  dependencies  and  graphic  output  of  milestone  schedules. 

The  types  of  requirements  identified,  by  originator,  are  shown  in  Table  4-4. 

Configuration  management  consisted  of  a  capability  to  track  ECP  status 
from  origination  through  Configuration  Control  Board  approval  and  to  provide 
configuration  status  accounting  and  audit  support. 

Finally,  three  respondents  identified  the  need  for  a  permanent  program 
support  library  or  software  archive.  Such  a  capability  would  provide  for 
(1)  a  software  back-up  for  catastrophic  failure  and  (2)  a  centralized  source 
of  software  routines  (common  and  unique) ,  test  scenarios/data,  and 
documentat ion . 

4. 1.1. 3  Logistics  Management  Support 

Due  to  the  constraints  of  the  Phase  1  interview  schedule,  the  logistics 
management  personnel  were  not  interviewed  as  extensively  as  were  the  engi¬ 
neering  personnel.  However,  applicable  requirements  documentation  has  been 
obtained  from  the  Management  Information  System  Steering  Committee.  This 
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Table  4-4.  PROJECT  PLANNING  AND  CONTROL  REQUIREMENTS 


System  or 
Organization 

Milestone 

Charting 

Schedule 

Tracking 

Resource 

Tracking 

Network 

Analysis 

AN/ALQ-119 

X 

X 

EWOLS/ECSAS 

X 

X 

X 

X 

AN/ALR-46 

X 

X 

X 

AN/ALR-69  (Update) 

X 

X 

X 

X 

AN/ALQ-131 

X 

X 

X 

EF-111A 

X 

X 

X 

AN/ALQ-155 

X 

X 

X 

AN/APR-38 

X 

X 

MMEC 

X 

X 

GPS 

X 

X 

MMRRW 

X 

X 

X 

MMRRAH 

_ * _ 

X 

X 

material  has  been  reviewed  and  included  for  the  Phase  2  analysis.  The 
following  main  areas  were  identified  in  this  documentation: 

•  Program  scheduling 

•  Production  planning 

•  ECP  tracking 

•  CDRL  monitoring 

•  Budget  projection 

These  requirements  have  been  investigated  in  Phase  2  and,  where  appro¬ 
priate,  integrated  with  the  Phase  1  interview  results. 

The  requirements  identified  to  date  are  oriented  to  program  planning 
and  tracking,  resource  planning  and  tracking,  and  budget  preparation  and 
monitoring;  they  include  the  following: 

•  Program  scheduling  and  milestone  tracking 

•  Resource  allocation  and  tracking 

•  Program  action  audit 

•  Program  documentation  storage  and  recall 

•  Contract  data  requirements  list  preparation 


•  Parts  reference  automation 

•  GFE  accountability 

•  Budget  analysis  and  preparation 

•  Budget  "checkbook"  maintenance 

4. 1.1. 4  Administrative  and  Division  Management  Support 

Administrative  and  management  support  requirements  fall  into  two 
broad  classes  —  control  requirements  and  information  requirements.  The 
management  information  requirements  of  the  Electronic  Warfare  Management 
Division  (MMR)  are  the  subject  of  a  current  study  by  an  MMR  Management 
Information  System  Steering  Committee.  They  were  not  addressed  in  Phase  1. 

A  number  of  management  and  administrative  control  requirements  were 
identified  in  Phase  1.  These  included  the  following: 

•  Document  control  (identification  and  location) 

•  Division  cost  accounting  and  projection 

•  Budget  monitoring 

•  Automated  mail  distribution 

•  Suspense  control 

•  Change  process  management 

Document  control  includes  logging,  cataloging,  and  tracking  of  docu¬ 
ments  received  or  generated  by  MMR.  Cost  accounting  and  projection  refers 
to  development  of  a  division  cost  accrual  system  capable  of  accumulating 
expenditures  of  manpower,  facilities,  consumables,  and  other  resources  by 
individual,  organization,  project,  or  foreign  military  sales  case.  This 
capability  would  then  provide  development  of  cost  planning  factors  for 
budget  projection.  Budget  monitoring  would  provide  management  with  budget 
status  by  organization,  system,  type,  or  source  of  funds.  Automated  mail 
distribution  and  suspense  control  would  provide  distribution  of  internal 
mail  by  cathode  ray  tube  (CRT);  establishment  and  notification  of  mile¬ 
stones,  suspense  dates,  and  items;  reporting  thresholds;  and  monitoring 
responses.  Change  process  management  would  provide  ECP  identification  and 
distribution,  status  reporting,  approval  control,  and  configuration  control 
board  agenda  development.  This  capability  would  logically  require  the 
suspense  control  capability  previously  identified. 

4.1.2  Support  Processor  Requirements 

Functional  requirements  of  a  support  processor  fall  into  four  areas 
—  support  software  development  tools,  software  test  tools,  architecturally 
implied  control  functions,  and  support  processor  management  functions.  For 
the  most  part,  support  software  development  tools  have  been  written  in 
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FORTRAN  IV.  This  requirement  to  support  FORTRAN  IV  will  continue  in  the 
near  future.  It  is  possible  that  increased  language  compilation  and  debug 
capabilities  may  be  required  from  1985  on.  Potential  candidates  for  this 
support  are  Ada,  JOVIAL  J(73),  Pascal,  COBOL,  FORTH,  CMS-2,  and  FORTRAN  IV. 

In  addition  to  requiring  compilers,  support  software  will  impose  many  of 
the  same  requirements  as  operational  software,  e.g.,  text  editing,  threat 
data  base  support,  VSV  tool  support,  documentation  support,  and  code  analysis 
and  optimization.  Software  test  tools  encompassed  a  variety  of  functions 
including  code  analysis  (syntax) ,  dynamic  analysis  (performance) ,  and  test 
data  generators . 

Another  area  of  support  processor  requirements  is  control  functions. 
These  functions  are  those  which  provide  for  the  orderly  implementation  of 
a  support  processor  architecture.  The  specific  functions  are  architecture- 
dependent;  therefore,  they  will  be  addressed  in  Phase  3  -  Alternative  Devel¬ 
opment.  However,  five  general  classes  of  functions  are  to  be  considered: 

•  Operating  systems  service 

•  Interactive  terminal  service 

•  Processor  networking  support 

•  Peripheral/processor  interface 

•  Security  access  control 

The  third  class  of  support  processor  functional  requirements  —  manage¬ 
ment  functions  —  is  somewhat  independent  of  architecture.  These  require¬ 
ments  were  identified  in  the  Phase  1  interviews: 

•  Applications  requirement  development  tracking 

•  Configuration  status  accounting 

•  System  performance  management 

•  Cost  accounting 

Many  of  these  functions  are  analogous  to  those  defined  for  the  EW  and 
avionics  systems,  e.g. ,  requirement  tracking  and  configuration  management. 
Others,  such  as  cost  accounting  for  usage  and  performance  measurement  and 
on-line  monitoring,  are  in  some  ways  unique  to  the  operation  of  large-scale 
support  processors.  Details  of  those  capabilities  identified  to  date  are 
included  in  the  appendix. 


4.2  REQUIREMENTS  ANALYSIS  RESULTS 

Phase  2  of  this  study.  Requirements  Analysis,  consisted  of  developing 
a  composite,  consensus  list  of  user  functional  requirements,  setting  prior¬ 
ities  among  the  requirements,  and  validating  a  set  of  requirements  for  the 
1985-and-beyond  EWAISF  support  processor.  The  composite  requirements  were 
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developed  by  iteratively  circulating  the  functional  requirements  identified 
in  Phase  1  to  the  users  for  comment,  coalescing  the  comments  into  composite 
requirements  descriptions,  and  submitting  them  to  the  users  for  final  review. 
The  priorities  of  requirements  were  developed  by  requesting  the  users  to 
rank  the  priorities  in  order  of  the  user's  need  for  the  function.  Finally, 
EWAISF  management  personnel  reviewed  the  composite  requirements  and  validated 
a  set  of  functions  to  be  pursued  in  subsequent  study  phases. 

4.2.1  Composite  Requirements 

The  functional  requirements  identified  in  Phase  1  were  presented  to 
the  users  in  the  following  categories: 

•  Software  change  support 

•  Other  engineering  support 

•  Division  management  support 

•  Logistics  management  support 

Users'  comments  were  consolidated  and  composite  descriptions  derived.  These 
were  submitted  to  the  users  in  the  above  categories,  and  final  comments 
were  incorporated.  As  a  result  of  the  functional  requirements  identified, 
a  fifth  category,  Implied  Functions,  was  developed.  The  resulting  composite 
requirements,  for  which  priorities  were  subsequently  set  and  which  were  pre¬ 
sented  for  validation,  are  presented  in  Table  4-5. 

4.2.2  Setting  Requirements  Priorities 

Concurrent  with  the  final  review  of  requirements  definitions,  the 
users  were  requested  to  rank  the  composite  requirements  in  order  of  the 
basis  of  need  or  desirability.  Approximately  50  percent  of  the  users 
responded.  The  results  are  shown  in  Table  4-6.  The  term  X  indicates  the 
mean  ranking  for  the  requirement,  while  the  term  0n  indicates  the  standard 
deviation  of  the  ranking.  Within  the  functional  areas,  rankings  were  very 
consistent,  i.e.,  engineering  personnel  ranked  requirements  similarly,  as 
did  logistics  management  personnel  and  MMEC  personnel. 

4.2.3  Requirements  Validation 

The  functional  requirements  and  their  priorities  were  presented  to 
EWAISF  management  personnel  in  two  separate  presentations.  The  first 
presentation  was  made  to  the  ISS  Support  Subcommittee  on  8  April  1981.  At 
that  meeting  the  subcommittee  divided  Jne  requirements  into  three  categories: 
required,  desired,  and  not  recommended.  Those  items  not  recdmmended  included 
Program  History,  Logistics  Support  Data  Base,  GFE  Accountability,  Repair 
Restrictions  Data  Base,  Checkbook,  Suspense  Tracking,  and  Automated  Mail 
System. 

The  requirements  presentation  was  repeated  to  the  EWAISF  Committee, 
along  with  the  recommendations  of  the  ISS  Support  Subcommittee.  The  EWAISF 
Committee  accepted  the  basic  recommendations  of  the  subcommittee,  but 
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Table  4-5. 

COMPOSITE  REQUIREMENTS 

Requirement 

Description 

Software  Change  Support 

Text/File  Edit 

Provide  capability  to  enter,  edit,  dupli¬ 
cate,  purge,  and  store  programs,  data, 
and  text  files  in  character  format.  The 
capability  should  provide  for  maintenance 
of  variable-length  records. 

Cross  Compilation/Assembly 

Provide  cross  compilation  and  assembly  of 
programs  for  target  processors. 

Automatic  Software 

Provide  capability  to  generate  software 

Documentation 

documentation  automatically,  i.e.,  memory 
maps,  subroutine  interface  listings,  and 
flow  charts. 

Threat  Data  Base  Maintenance 

Provide  maintenance  of  the  EWIR  or  other 
threat  data  bases  and  extract,  sort,  and 
format  threat  data  for  use  by  other 
systems . 

Data  Reduction/Analysis 

Allow  input  of  data  from  ISS  or  flight 
test  (including  pod-recorded  data)  and 
provide  generalized  correlation  and  report 
formatting  capabilities. 

V&V  Test  Support 

Provide  software  test  tools  to  support 
software  V&V.  These  may  be  generalized  or 
specific  to  a  target  processor  and  include 
test  data  generators  and  smart  editors. 

V&V  Tracking 

Provide  change  traceability  for  test 
tracking  purposes. 

Emulation 

Provide  a  generalized  capability  to  emu¬ 
late  other  processors  for  software  debug. 

Change  Distribution 

Provide  an  automated  medium  for  distribu¬ 
tion  of  software  changes  to  the  field. 

Data  Table  Generation 

Provide  the  capability  to  output  data 
table  messages  for  field  updates. 

(continued) 
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Requirement 

Description 

Software  Change  Support  (continued) 

On-Line  Simulation 

Provide  for  on-line  digital  environment 
simulation  (1)  to  provide  operating  envi¬ 
ronment  for  processor  emulations  or  (2)  to 
provide  a  test  environment  in  the  event 

RF  test  equipment  or  portions  of  hot 
bench  mock-up  are  unavailable. 

Other  Engineering  Support 

Compilation 

Provide  compilation  and  assembly  capabil¬ 
ity  for  software  generated  in  DoD- approved 
HOLs. 

ECS  and  ISS  Documentation 
Maintenance 

Provide  a  capability  to  enter,  edit,  and 
produce  system  documentation.  This 
includes  the  capability  to  insert,  delete, 
modify,  tabulate,  paginate,  search  the 
text,  and  provide  headers  and  footings. 

ISS  Configuration  Management 

Provide  maintenance  and  monitoring  of  ISS 
hardware  configurations  (e.g.,  ISS  wire- 
lists)  and  provide  engineering  drawings 
for  layouts  and  wire  runs. 

Training 

Provide  interactive,  programmed  instruc¬ 
tion  in  the  use  of  the  support  processor. 

Software  Code  Analysis 

Provide  syntactic  and  semantic  analysis 
and  optimization  of  software. 

Software  Performance 

Analysis 

Provide  a  capability  to  analyze  software 
implementations  to  determine  choke  points, 
frequency  of  code  execution,  instruction 
timings,  and  other  performance  parameters 
in  order  to  fine  tune  the  software  in 
response  to  changing  requirements. 

System  Modeling 

Provide  off-line  simulation  to  evaluate 
system  design  and  software 
implementations . 

(continued) 
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Table 

4-5.  (continued) 

Requirement 

Description 

Other  Engineering  Support  (continued) 

Software  Conversion  Support 


Provide  syntactic  analysis  and  transla¬ 
tion  of  software  languages  for  conversion 
of  ISS  or  support  processors. 


Program  Support  Library 


Provide  a  central  library  and  code  con¬ 
trol  for  current  software,  test  data,  and 
scenarios. 


Software  Archive 


Provide  a  back-up  software  archive  and 
data  management  function. 


Project  Control 


Division  Management  Support 


Provide  for  monitoring  of  assigned  section 
projects.  This  includes  tracking  of  mile¬ 
stones  and  dates  and  monitoring  of 
resource  assignment.  The  capability 
should  allow  planning  and  analysis,  e.g., 
PERT  or  critical  path  modeling.  It 
should  also  provide  the  ability  to  produce 
graphic  representations  of  the  project 
schedules. 


Configuration  Management 


Document  Control 


Provide  for  automated  support  of  the  con¬ 
figuration  management  process,  including 
ECP  initiation  and  tracking,  suspense 
management,  CPCSB  agenda  development, 
block-cycle  reporting. 

Provide  capability  to  identify,  catalog, 
and  locate  system  ECS  and  ISS 
documentation . 


Logistics  Management  Support 


Budget  Preparation 


Provide  automated  maintenance  of  the  pro¬ 
gram  budget  data  base  and  creation  of 
budgetary  submissions  and  consolidate  data 
for  all  budget  sources. 


Table 

4-5.  (continued) 

Requirement 

Description 

Logistics  Management  Support  (continued) 

Life-Cycle-Cost  Analysis 

Provide  a  model  for  projection  of  system 
life-cycle  costs  based  on  varying  support 
concepts,  program  and  equipment  changes, 
and  changes  in  requirements  parameters. 

Procurement  Preparation 

Provide  for  automated  support  to  develop 
Contract  Data  Requirements  List  (CDRL) . 
Standard  packages  of  data  item  descrip¬ 
tions  would  be  developed  and  maintained 
for  selection,  modification,  or  inclusion 
in  the  procurement  package. 

System  History 

Provide  capability  to  create  an  automated 
audit  trail  of  program  budget,  logistics, 
and  technical  actions.  The  function  would 
allow  continuity  of  program  processes  even 
though  personnel  might  shift. 

Logistics  Support  Data  Base 

Provide  an  automated  parts  reference  data 
base  to  include : 

•  Parts  Numbers 

•  Descriptive  Data 

•  Maintenance/Repair  Codes 

•  Requirements  Factors 

•  Interchangeability 

•  Special  Tools 

The  requirement  would  also  provide 

Logistics  Support  Analysis  (LSA)  records 
and  level-of-repair  (LOR)  analysis. 

GFE  Accountability 

Provide  identification  and  scheduling  of 

GFE  requirements  and  monitoring  status  and 
accountability  and  disposition  of  GFE 
items. 

Repair  Restrictions  Data 

Base 

Provide  a  reference  of  NSN  repair  restric¬ 
tions  by  system  and  aircraft  type. 

Table 

4-5.  (continued) 

Requirement 

Description 

Logistics  Management  Support  (continued) 

Checkbook 


Suspense  Tracking 


Automated  Mail  System 


Provide  MMR  personnel  with  budgetary 
"checkbooks"  to  account  for  the  status  of 
funds  by  source,  type,  recipient,  and 
purpose,  and  to  provide  an  audit  trail  of 
budgetary  actions. 

Provide  for  establishment  of  suspense 
items  and  notification  of  related  thresh¬ 
old  and  exception  conditions. 

Provide  a  means  for  rapid  distribution  of 
internal  mail,  assignment  and  tracking  of 
associated  suspenses,  creation  of  audit 
trails,  and  notification  of  recipients. 


Security* 


System  Management 


Implied  Functions 


Provide  system,  program,  and  data  access 
control,  and  implement  appropriate  output 
and  data  safeguards  as  required  by  system 
architecture. 

Determine  system  usage  by  EW  system,  user, 
and  individual?  monitor  system  performance 
(e.g.,  I/O  wait  times,  memory  allocations, 
throughput);  and  dynamically  control 
system  resources. 


Cost  Accounting 


Provide  a  cost  accrual  and  estimation 
system.  Costs  must  be  accrued  by  project, 
individual  system,  and  budgetary  source. 
The  system  will  also  provide  internal 
planning  data. 


‘Security  was  not  included  in  the  priority-setting  survey,  since  it  is 
a  mandated,  yet  architecture-dependent  function. 
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Table  4-6.  PRIORITIES  OF 

REQUIREMENTS 

Priority 

Rankings 

Function 

Including 

MMEC 

Not 

Including 

MMEC 

X* 

0  ** 

n 

a 

a  ** 

n 

Threat  Data  Base 

Maintenance 

5.1 

6.3 

2.8 

2.4 

Data  Reduction/Analysis 

7.8 

5.7 

5.8 

2.0 

Cross  Compilation/Assembly 

8.2 

7.1 

7.3 

6.1 

V&V  Tracking 

8.5 

4.0 

6.9 

2.3 

Text/File  Edit 

9.1 

8.2 

11.8 

7.8 

Compilation 

10.2 

4.3 

10.0 

4.9 

V&V  Test  Support 

10.5 

10.7 

11.7 

12.0 

Program  Support  Library 

10.9 

5.5 

9.8 

5.3 

ECS  and  ISS  Documentation 
Maintenance 

11.1 

5.4 

12.5 

4.9 

Software  Archive 

11.1 

5.4 

10.7 

5.3 

Automatic  Software 
Documentation 

11.7 

10.1 

13.2 

11.3 

Change  Distribution 

11.9 

7.5 

9.5 

3.4 

Configuration  Management 

12.1 

12.3 

14.2 

13.5 

Software  Code  Analysis 

12.5 

6.3 

11.5 

2.3 

Software  Performance 
Analysis 

13.1 

5.9 

12.3 

2.6 

ISS  Configuration 

Management 

14.5 

6.3 

12.5 

5.6 

Software  Conversion 

Support 

16.4 

8.3 

13.7 

4.3 

System  Modeling 

17.9 

5.8 

15.7 

5.0 

On-Line  Simulation 

18.8 

11.8 

17.7 

9.8 

Data  Table  Generation 

20.1 

10.9 

22.0 

11.0 

*X  =  mean  ranking. 

**0  =  standard  deviation, 

n 

(continued) 
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Table  4-6.  (continued) 


Priority 

Rankings 

Function 

Including 

MMEC 

Not 

Including 

MMEC 

X* 

0  ** 

n 

X* 

0  ** 

n 

Project  Control 

21.5 

10.4 

19.8 

n.i 

Training 

22.0 

7.8 

22.8 

7.5 

System  Management 

22.8 

7.8 

23.8 

7.9 

Emulation 

22.8 

12.9 

23.7 

11.0 

Budget  Preparation 

24.1 

5.9 

26.7 

4.5 

Document  Control 

24.4 

10.2 

24.5 

11.1 

Checkbook 

25.3 

10.4 

24.3 

11.5 

Procurement  Preparation 

25.7 

6.1 

27.2 

5.4 

Cost  Accounting 

25.9 

9.7 

24.8 

10.6 

Life-Cycle-Cost  Analysis 

28.0 

5.1 

28.2 

2.7 

Suspense  Tracking 

28.0 

10.5 

27.8 

11.5 

System  History 

28.6 

4.5 

27.2 

4.4 

Documentation  Archive 

28.7 

4.2 

27.6 

4.5 

Logistics  Support  Data 

Base 

29.0 

4.8 

29.2 

2.0 

GFE  Accountability 

29.3 

1.7 

29.6 

1.9 

Repair  Restrictions  Data 
Base 

29.7 

2.4 

28.8 

1.2 

Automated  Mail  System 

31.0 

9.8 

29.5 

10.8 

*X  =  wean  ranking. 

**<J  =  standard  deviation, 

n 


restored  the  Checkbook  Function  to  the  desired  list.  The  functions  were 
divided  into  three  categories  —  required,  desired,  and  identified  —  and 
reviewed  for  unique  application  to  the  EWAXSF.  The  resulting  validated 
requirements  are  shown  in  Tables  4-7,  4-8,  and  4-9.  Those  requirements 
shown  in  Table  4-9,  Identified  Functions,  while  validated  as  MMR  require¬ 
ments,  were  eliminated  from  further  consideration  of  this  study.  It  was 
determined  that  these  functions  would  be  "addressed  more  appropriately  in 
a  separate  forum."* 

*EWAISF  Committee  Meeting  Minutes,  9  April  1981,  dated  16  April  1981. 
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REQUIRED  FUNCTIONS  I  I  Table  4-8.  DESIRED  FUNCTIONS 
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Implied  Functions  I  I  Automated  Mail  System 


Composite  specifications  for  the  required  functions  are  contained  in  Appendix 
B,  Figures  B- 1  through  B-23,  and  for  the  desired  functions  in  Figures  B-24 
through  B-31.  The  information  presented  in  these  figures  is  described  in 
Section  3.2. 

4.2.4  ADPE  and  Software  Requirements 

The  first  two  phases  of  this  study  have  dealt  primarily  with  identify¬ 
ing  and  validating  a  set  of  functional  requirements  for  an  EWAISF  support 
processor.  The  conclusion  of  Phase  2  (Requirements  Analysis)  provides  the 
basis  for  development  of  architectural  alternatives  for  a  support  processor. 
Therefore,  it  is  necessary  to  translate  the  validated  functional  require¬ 
ments  into  computer  processing  terms  to  support  the  alternative  development. 
These  ADPE  and  software  requirements,  as  synthesized  from  the  functional 
requirements,  are  presented  in  four  general  categories  —  generalized  sup¬ 
port  software,  applications  software,  operating  system  and  executive  soft¬ 
ware,  and  equipment  requirements.  These  requirements  have  been  synthesized 
by  the  author  on  the  basis  of  experience. 

4. 2. 4.1  Generalized  Support  Software 

Generalized  support  software,  for  the  purpose  of  this  study,  is  defined 
as  software  capable  of  supporting  multiple  applications  without  modification. 
Inspection  of  the  validated  definitions  of  required  and  desired  functions 
identified  the  following  generalized  software  capabilities  as  being  required 
in  the  EWAISF  support  processor: 

•  Data  Base  Management  System 

•  Text/File  Editor 

•  Document  Processor 

•  Compilers  and  Assemblers 

•  Static  and  Dynamic  Code  Analyzers 

•  Statistical  Analysis  Library 

•  Emulation  Compiler 

The  data  base  management  system  (DBMS)  should  furnish  data  definition, 
maintenance,  and  retrieval  services  to  the  various  applications  software 
resident  in  the  support  processor,  as  well  as  interactive -user  data  storage 
and  retrieval  and  source  data  for  other  processors.  The  DBMS  should  have 
the  capability  to  define  data  items  and  their  characteristics  and  the  rela¬ 
tionships  of  data  items  and  groups  of  data  items.  These  definitions  should 
give  the  user  or  programmer  symbolic,  device-independent  data  access.  The 
data  bases  identified  or  projected  to  date  pose  no  requirements  that  would 
dictate  a  particular  structure,  e.g.,  chained,  hierarchical,  or  networked 
records.  However,  the  DBMS  should  permit  linked,  multifile  relationships. 

The  data  definition  capability,  in  addition  to  permitting  standard  data- 
item-attribute  definitions  and  record-structuring,  should  also  provide 
data-access  security  specifications  at  least  to  the  data-base  level,  by 
user.  The  definition  capability  should  be  interactive  and  easily  understood 
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and  used  by  nonprogramming  personnel.  The  system  should  readily  prompt 
users  for  required  definition  information  and  should  permit  immediate  inter¬ 
active  correction  of  definition  errors.  The  DBMS  must  provide  interactive- 
user  data  maintenance  facilities  as  well  as  program-callable  data  services. 

In  addition  to  normal  record  and  data-item  maintenance  features,  the  DBMS 
should  permit  redefining  data  structures,  bulk-load  data  bases,  and  copy 
and  subset  data  bases,  and  creating  audit  trails  of  maintenance  actions. 

The  DBMS  must  have  features  that  ensure  integrity  of  the  data  base,  including 
checkpoint,  save  and  restore,  and  data  pointer  analysis. 

The  text/file  editor  must  have  the  capability  to  create  and  maintain 
source  data,  program  files,  and  document  text.  This  feature  should  permit 
text  entry,  edit  (add,  delete,  and  change),  text  search  on  character 
strings,  and  replacement  and  movement  of  text.  Auxiliary  features  include 
bulk-data- loading,  file  save  and  restoration,  and  cataloging.  This 
capability  must  include  maintenance  of  variable-length  records.  In  addition, 
a  page-formatting  and  -editing  capability  is  required  to  permit  interactive 
definition  of  screen  formats,  field  protection,  and  field  data  types. 

The  document  processor  should  facilitate  the  automatic  generation  and 
maintenance  of  system  documentation .  It  may  interface  with  the  text  editor 
but  could  utilize  its  own  input  source.  It  must  provide  a  facile  interface 
for  clerical  personnel  for  the  formatting  and  maintenance  of  documentation. 
Specifically,  the  document  processor  must  have  a  capability  for  interface 
to  the  DBMS  or  text/file  editor  for  data  extraction;  document  formatting  to 
include  insertion,  deletion,  modification,  tabulation,  pagination,  headings, 
and  footings;  provision  for  including  figures  and  tables;  and  automated 
interface  to  software  documentation  tools.  It  should  provide  a  text  search 
on  character  strings  or  Key-Word- In-Context  and  an  automated  indexing  of 
key  terms.  The  processor  should  provide  for  identification  and  dating  of 
document  versions. 

Two  classes  of  compilers  and  assemblers  must  be  provided  by  the  EWAISF 
support  processor.  The  first  class  consists  of  the  support  processor  assem¬ 
bler  and  HOL  language  compilers  to  support  development  of  software  tools. 

The  second  class  consists  of  cross  compilers  and  assemblers  for  the  system 
target  processors  identified  in  Table  4-1  and  for  the  ECS/ISS  host  processors. 
HOLs  for  which  compilation  must  be  provided  include  FORTRAN  IV,  COBOL,  Ada, 
JOVIAL  J(73),  Pascal,  CMS-2,  and  FORTH.  Compiler  and  assembler  provisions 
must  readily  accommodate  changes  in  system  processors  and  ECS/ISS  host 
processors. 

Code  analyzers  must  provide  two  distinct  capabilities:  (1)  analysis  of 
source  code  for  quality  control,  verification,  and  optimization,  and  (2) 
dynamic  analysis  of  executing  software  to  determine  performance  parameters 
in  an  operating  environment.  The  source  code  analyzers  must  be  capable  of 
checking  language  syntax  for  correctness  and  adherence  to  standards,  logic 
flow,  and  variable  usage.  The  analyzers  should  also  permit  local  and  global 
code  optimization  through  identification  of  common  software.  Dynamic- 
performance-analysis  software  should  be  capable  of  collecting,  formatting, 


and  presenting  execution  statistics  that  show  frequency  execution  of  soft¬ 
ware  routines,  processing  and  I/O  times  by  routine,  wait-state  durations, 
and  memory  utilization.  This  software  is  oriented  to  the  applications 
programs  and  is  independent  of  the  normal,  operating-system-accounting 
functions. 

The  statistical  analysis  software  must  permit  examining  an  input  data 
set,  sorting  the  set  on  multiple  data  fields  in  either  ascending  or  descending 
order,  and  selecting  items  of  information  to  create  subsets  of  the  input  data 
sets.  This  feature  must  be  able  to  do  the  following: 

•  Perform  counts  and  totals 

•  Perform  curve-fitting  algorithms 

•  Compute  standard  statistical  parameters 

•  Format  the  input  data  and  derived  statistics  for  presentation  in 
both  tabular  and  graphic  forms 

•  Interface  with  the  document  processor  for  inclusion  of  tables  and 
figures  in  documentation 

•  Accept  data  from  a  variety  of  sources,  including  hot  bench  mock- 
ups,  flight-test  recording  media,  and  dynamic  software  analysis 
packages 

The  emulation  compiler  is  a  requisite  capability  for  the  implementation 
of  a  generalized  processor  emulation  capability.  This  feature  defines  the 
architecture  and  instruction  set  of  the  emulated  processor  to  the  emulator 
host  processor.  The  compiler  must  be  capable  of  accepting  the  definition 
via  an  input  data  set  and  producing  microcode  capable  of  performing  all  emu¬ 
lated  processor  instructions. 

4. 2. 4. 2  Applications  Software 

Applications  software  consists  of  software  unique  to  the  support  of  a 
single  functional  requirement.  These  packages  may  be  commercially  available 
or  may  require  development.  Applications  software  may  also  utilize  the 
generalized  support  software ,  as  well  as  executive  and  operating-system- 
software  services,  in  accomplishing  its  function.  Applications  software 
will  be  required  to  support  the  following  functions: 

•  Automatic  software  documentation 

•  Data  reduction/analysis 

•  V&V  test  support 

•  Change  distribution 

•  Data  table  generation 

•  ISS  configuration  management 

•  Training 
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•  Program  support  library 

•  Configuration  management 

•  Document  control 

•  On-line  simulation 

•  V&V  tracking 

•  System  modeling 

•  Budget  cycle  preparation 

•  Life-cycle-cost  analysis 

•  Procurement  preparation 

•  Checkbook  maintenance 

These  application  packages  vary  widely  in  size  and  complexity.  Almost 
all  require  an  interactive  interface.  More  than  50  percent  require  an  inter 
face  to  the  data  base  management  system,  including  applications-unique  data 
base  definitions,  editing  criteria,  maintenance ,  and  extraction  and  sort 
routines.  Several  could  utilize  the  report-generation  capability  of  the 
document  processor.  Table  4-10  characterizes  the  applications  packages, 
including  estimates  of  their  use  of  generalized  support  software  and  sizes 
in  terms  of  lines  of  code. 

4.2.4. 3  Operating  System  and  Executive  Software 

The  operating  system  (OS)  and  executive  software  for  the  support  proc¬ 
essor  must  provide  multiprogramming  support  in  batch  and  interactive  modes. 
The  OS  must  permit  program  initiation  and  normal  and  abnormal  termination 
(including  fault- trapping) ,  as  well  as  management  of  main  and  peripheral 
resources  (including  allocation  and  de-allocation  of  memory  and  peripherals) 
It  must  have  the  capability  for  interface  to  the  various  ISS  ECS  processors 
and  peripheral  support  to  mass  storage,  display,  and  record  devices.  It 
must  provide  data  management  (file  and  record)  services  to  applications  pro¬ 
grams,  as  well  as  interprocess  communications. 

In  addition  to  the  normal  operating  system  services,  the  support 
processor  must  offer  security,  system  management,  and  cost-accounting 
functions.  Security  includes  system  access  control,  output  labeling  and 
control,  and  data  security  and  integrity  functions  for  both  covert  and  in¬ 
advertent  compromise  situations.  All  security  software  must  be  capable  of 
modification  to  satisfy  the  requirements  for  the  mode  of  operation  in  which 
the  system  operates.  The  system  must  permit  monitoring  system  component 
usage,  recording  and  analyzing  faults,  and  isolating  failed  components  from 
the  system.  The  OS  must  provide  the  capability  to  implement  a  usage¬ 
accounting  algorithm  for  analyzing  system  operating  costs. 

Most  if  not  all  of  the  above  requirements  are  satisfied  in  one  form  or 
another  by  commercially  available  operating  systems.  Some  executive  soft¬ 
ware  is  still  required  to  implement  these  functions  but  is  dependent  on  the 
architecture  selected. 


Table  4-10.  APPLICATIONS  SOFTWARE 


Checkbook  Maintenance 


4. 2. 4. 4  ADPE  Requirements 

To  a  large  extent,  equipment  requirements  are  dependent  on  the 
architecture  to  be  implemented.  However,  certain  general  requirements  can 
be  derived  on  the  basis  of  functional  requirements.  Required  character¬ 
istics  of  the  support  ADPE  for  the  EWAISF  are  presented  in  this  section 
for  the  processors,  mass  storage,  user  terminals,  display  devices,  and 
communications.  In  establishing  the  ADPE  requirements,  the  following 
assumptions  have  been  made : 

•  The  EWAISF  workload  is  a  direct  function  of  the  number  of  systems 
supported. 

•  The  software  change  function  will  be  carried  out  primarily  on  the 
ISS  processors. 

•  The  support  processors  will  be  interactively  accessed  by  one 
terminal  for  every  two  systems  at  any  given  time. 

•  During  emergency  change  conditions,  each  individual  using  the 
support  processors  will  require  daily  access. 

•  Mass  storage  will  be  required  for  all  functional  data  bases 
(e.g.,  EWIR)  for  all  current  versions  of  EW  systems  and  ISS 
documentation . 

•  ISS  processors  will  be  linked  to  the  support  processors  for  data 
transfer,  including  software  updates,  documentation  updates,  and 
base  retrievals. 

•  The  engineering  function  will  be  wholly  contained  within  controlled 
areas. 

•  To  the  extent  practicable,  the  alternative  architectures  will  be 
compatible  with  planned  ISS  processor  architectures. 

Given  these  assumptions,  the  ADPE  requirements  have  been  derived  as 
described  in  the  following  paragraphs. 

Processors 


The  processors  providing  the  EWAISF  support  functions  can  be  charac¬ 
terized  in  the  following  terms  —  speed,  memory,  and  data  types.  If  it 
is  assumed  (1)  that  one-half  of  the  systems  will  be  using  the  support 
processor  capability  at  a  given  time,  (2)  that  one-half  of  the  interactive 
terminals  are  attached,  (3)  that  the  average  process  requires  25  iterations 
of  one-half  its  code,  (4)  that  the  average  process  size  is  5,000  instruc¬ 
tions  (see  Table  4-10) ,  (5)  that  system  overhead  is  25  percent,  and  (6) 
that  system  growth  is  anticipated  to  be  50  percent,  then  the  following 
processor  speed  requirement  can  be  calculated  on  the  basis  of  a  two-second 
response  time: 

Instructions  per  second  =  (16  systems  r  2) 

x  (25  iterations  per  system) 
x  (5,000  instructions  per  iteration  v  2) 
x  (1.25  overhead)  x  (1.5  growth)  t  (2  seconds) 
=  468,750 
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For  a  single  processor,  this  processing  rate  requires  an  instruction 
execution  time  of  approximately  two  microseconds. 

The  required  main  memory  capacity  of  the  system  is  a  function  of  the 
architecture  selected,  the  speed  of  the  processors,  and  the  type  of  opera¬ 
ting  system  used  (physical  versus  virtual  memory) .  A  static  memory 
requirement  (i.e.,  one  that  does  not  impact  the  speed  requirement  previously 
identified)  can  be  calculated  from  the  following  assumptions: 

•  One-half  of  the  EW  system  processors  are  using  the  support 
processors  at  a  given  time. 

•  Time-sharing  or  terminal-handling  processes  are  always  active,  as 
are  the  operating  system,  accounting,  and  diagnostic  software,  and 
require  memory  equal  to  25  percent  of  the  applications  memory 
requirement . 

•  The  average  process  contains  5,000  instructions  of  1-1/2  word 
lengths . 

•  Data  areas  for  each  process  are  ten  times  the  size  of  the  instruction 
area. 

•  A  50  percent  growth  is  anticipated. 

The  memory  requirement  can  then  be  calculated  as  follows: 


Words  of  main  memory  =  (16  systems  v  2)  x  (1.25  overhead) 

x  (7,500  instruction  words  per  system) 
x  (11  words  per  instruction  word)  *  (1.5  growth) 
=  1,237,500  words 

This  requirement  can  be  adjusted  on  the  basis  of  operating  system  or 
architecture.  The  word  size  of  the  processor  should  be  sufficient  for 
32-bit  arithmetic  in  either  single-  or  double-word  mode. 

The  processor  will  supp-'ct  data  base  and  computation  applications  and 
therefore  must  provide  a  variety  of  data  types,  including  integer,  floating 
point,  bit  strings,  character  strings,  and  packed  decimal.  If  the  word 
length  of  the  processor  is  16  bits,  a  double-word,  floating-point  capa¬ 
bility  must  be  provided. 

Mass  Storage 


The  mass  storage  available  for  the  support  processors  must  provide  both 
on-line  and  archival  storage  capability.  Archival  storage  can  be  provided 
by  magnetic  tape  units.  Assuming  that  one-half  of  the  systems  are  actively 
using  the  support  processors,  that  one-fourth  of  these  require  archival 
storage,  and  that  two  drives  are  available  for  system  usage,  then  a 
minimum  of  four  tape  drives  would  be  required.  On-line  storage  would 
consist  of  magnetic  disk.  The  EW  systems'  Resource  Acquisition  Management 
Plans  (RAMPs)  indicate  an  ISS  magnetic  disk  storage  capability  ranging 


from  10^  bytes  to  8  x  10^  bytes.  Using  an  average  figure  of  30  Mbytes  per 
system  and  16  systems  yields  a  requirement  for  480  Mbytes  of  on-line  storage 
for  an  EW  system  and  for  ISS  software  and  data  back-up.  An  earlier  EWAISF 
documentation  study  estimated  30  man-years  of  documentation  input  time, 
based  on  a  typing  speed  of  50  words  per  minute,  5  characters  per  word, 
and  2,000  man-hours  per  man-year.  Therefore,  the  total  number  of  characters 
of  documentation  is : 

(30  man-years)  x  (2,000  man-hours  per  man-year) 
x  (60  minutes  per  man-hour)  x  (50  words  per  minute) 
x  (5  characters  per  word) 

=  900  x  106  characters  =  900  Mbytes  storage 

Thus  the  total  disk  storage  requirement  is  1,380  Mbytes  plus  25  percent 
overhead  for  a  total  of  1,725  Mbytes. 

User  Terminals 

User  terminals  will  be  required  to  support  each  system  as  well  as  the 
engineering  management  functions.  It  is  assumed  that  8  of  the  16  supported 
systems  will  require  1  terminal,  and  8  will  require  2  cerminals,  for  a  total 
of  24  terminals.  In  addition,  engineering  management  will  require  1 
terminal  each  for  branch  and  section  chief,  for  a  total  of  7.  Requirements 
for  terminals  to  support  the  software  support  organizations  will  depend  on 
the  software  support  concept  employed.  However,  for  preliminary  sizing 
purposes,  an  estimate  of  10  terminals  for  the  support  function  is  assumed, 
which  allows  for  some  pooling  of  terminal  resources  for  overflow  usage. 

The  total  terminal  requirement  is  41. 

The  physical  characteristics  of  the  terminals  are  dependent  on  the 
architecture  (e.g. ,  smart  versus  dumb) ,  but  some  can  be  specified.  Each 
terminal  should  provide  a  CRT  display  of  at  least  80  characters  by  20 
lines  and  should  be  capable  of  displaying  the  complete  seven-bit  ASCII 
character  set  (128  codes).  Graphics  display  is  not  a  requirement  but  is 
a  desirable  attribute.  Standard  keyboard  data  entry  is  required,  and 
programmable  function  keys  are  desirable.  For  those  terminals  in  the 
engineering  management  area,  a  forms  capability  with  protected  fields  is 
desirable. 


Display  Deviceo 

Required  display  devices  include  printers  and  plotter  graphics.  The 
stated  requirement  of  local  print  capability  has  security  ramifications 
that  are  architecture-dependent.  On  the  basis  of  current  usage,  it  is 
apparent  that  two  high-speed  line  printers  (more  than  1,000  lines  per 
minute)  should  be  adequate  to  provide  centralized  printing  capability.  If 
security  considerations  do  not  preclude  establishment  of  remote  print 
facilities  (one  printer  per  floor),  then  a  local  print  capability  of 
400  to  600  lines  per  minute  should  be  sufficient  for  small  print  files. 

The  two  high-speed  printers  (based  on  1,400  lines  per  minute)  would 


provide  a  one-shift  print  capability  of  168  million  lines  per  year  based 
on  a  50  percent  duty  cycle.  The  initial  documentation  entry  is  the 
largest  print  requirement,  with  36  million  lines.  A  single,  large  flatbed 
plotter  should  be  adequate  for  all  large-scale  plot  requirements.  However, 
if  user  terminals  with  graphics  capability  are  acquired,  a  graphics-capable 
page-print  device  (for  such  items  as  milestone  charts)  should  be  provided. 

Communications 


Communications  requirements  for  the  system  include  the  support  of  all 
interactive  terminals  at  a  2,400  baud  rate  on  a  50  percent  duty  cycle.  In 
addition,  medium-speed  interfaces  (9,600  to  19,200  baud)  should  provide 
adequate  data  transfer  between  the  support  processors  and  the  ISS  edit 
control  station  processors.  The  major  high-speed  interface  requirement  is 
the  interface  between  the  support  processors  and  the  emulation  processor 
for  environmental  simulation,  which  is  architecture-dependent.  This  will 
require  an  interface  of  100  Kbaud  or  faster. 
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CHAPTER  FIVE 


ALTERNATIVE  SUPPORT  ARCHITECTURES 


Phase  3,  Alternatives  Definition,  provides  alternative  architectures 
for  implementing  the  EWAISF  support  functions  identified  and  validated  in 
Phases  1  and  2  of  this  effort.  These  architectures,  in  addition  to  respond¬ 
ing  to  the  support  functional  requirements,  consider  the  ADPE  and  software 
requirements  synthesized  in  Phase  2.  The  alternatives  form  the  basis  for 
the  cost-benefit  analysis  performed  in  Phase  4.  The  alternatives  identi¬ 
fied  in  this  phase  were  not  restricted  by  existing  modes  of  operation. 

Four  initial  architectures  were  identified,  as  follows: 

•  Independent.  This  architecture  is  characterized  by  the  absence  of 
control  or  physical  connectivity  between  systems  and  the  support 
processors.  It  utilizes  one  large  mainframe  in  a  manner  similar 
to  the  current  operation. 

•  Federated  (Single  Processor).  This  architecture  would  employ  a 
large  mainframe  computer  in  a  loosely  coupled  EWAISF  operation. 

(In  this  context,  loosely  coupled  signifies  connectivity  for  the 
purpose  of  data,  but  not  for  control  flow). 

«  Federated  (Multiple  Processor) .  This  architecture  would  consist 
of  functionally  distributed  multiple  processors  of  a  smaller  size 
than  that  of  the  single-processor  configuration.  This  set  of 
processors  would  constitute  the  support  processor  function. 

•  Integrated.  This  architecture  would  integrate  the  EWAISF  support 
functions  in  a  workload  distribution  network  consisting  of  the  ISS 
processors  and  augmented,  as  required,  to  provide  the  necessary 
processing  power. 

The  requirements  identified  in  Phases  1  and  2  necessitate  data  links  between 
the  support  processor  and  the  ISS  processors  for  on-line  data  transfer,  up¬ 
date,  and  inquiry  functions.  The  Independent  Architecture  does  not  provide 
the  required  connectivity,  and  was,  therefore,  eliminated  from  further 
consideration . 

The  remaining  three  architectures  were  presented  to  the  ISS  Support 
Subcommittee  at  its  regularly  scheduled  June  meeting.  At  this  meeting, 
it  was  concluded  that  the  Integrated  Architecture  had  substantial  technical 
risk  and  was  probably  not  affordable.  This  architecture  was  subsequently 
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replaced  by  a  federated  architecture  employing  front-end  processors  for 
terminal  management  and  coordination  of  common  processes  between  the  support 
processors  and  the  ISS  processors.  Thus  three  federated  architectures  were 
approved  for  further  consideration: 

•  Single  processor 

•  Multiple  processor 

•  Front-end  processors 

Each  of  these  architectures  is  defined,  in  terms  of  concept,  components, 
and  interfaces,  in  greater  detail  in  the  following  sections.  These  archi¬ 
tectures  will  be  subsequently  evaluated  in  Phase  4  —  Cost-Benefit  Analysis. 
Phase  4  will  address  low-  and  high-cost  options  for  each  architecture.  The 
low-cost  options  will  implement  those  functions  validated  as  required  in 
Phase  2.  The  high-cost  options  will  implement  the  required  functions  and 
also  those  functions  validated  as  desired. 


5.1  SINGLE-PROCESSOR  ARCHITECTURE 

5.1.1  Concept 


As  mentioned  previously,  the  Single-Processor  Architecture  is  based  on 
a  single,  large  mainframe  computer  that  is  used  to  provide  all  EWAISF  support 
data  and  computation  functions.  These  functions  would  be  established  in  a 
separate  support  processor  organization  that  provides  interactive  processing 
support  to  engineering  personnel  and  over-the-counter  service  for  output 
control  and  batch  job  submissions.  In  the  high-cost  option,  a  separate 
emulation  processor  is  added.  Environmental  simulation  for  this  processor 
would  be  provided  by  the  mainframe  processor.  It  is  possible,  despite  siz¬ 
ing  estimates,  that  during  an  emulation,  the  mainframe  processor  would  need 
to  be  dedicated  for  environmental  simulation. 

The  user  interface  would  be  provided  by  directly  attached  interactive 
terminals.  The  terminals  would  be  dedicated  to  support  processor  access. 

The  ISS  processors  would  also  be  linked  to  the  mainframe  computer  for  data 
transfer  functions.  This  transfer  would  permit  transmission  of  print  files 
for  printing  on  the  ISS  printers. 

Operational  support  of  the  support  processor  would  be  provided  by  the 
support  processor  organization.  Operational  support  of  the  ISS  computer 
systems  would  be  provided  by  the  engineers  assigned  to  the  systems,  which 
reflects  the  current  support  concept. 

Security  aspects  of  this  architecture  include  the  following: 

•  All  support  processor  operations  would  be  centrally  located. 

•  No  terminal  equipments  would  require  interfaces  that  would  exit 
the  controlled  areas . 

•  Physical  security  would  be  accomplished  in  the  current  manner. 

•  TEMPEST  requirements  would  be  satisfied  in  the  current  manner. 
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Figure  5-1  is  a  block  diagram  of  the  Single-Processor  Architecture.  This 
architecture  consists  of  processors,  interactive  terminals,  an  archival 
storage  subsystem,  an  on-line  mass  storage  subsystem,  a  hard-copy  display 
subsystem,  and  associated  communications  and  software. 

5.1.2  System  Components 

The  components  that  constitute  the  support  processor  subsystems  are 
described  in  the  following  paragraphs. 

5. 1.2.1  Processors 

The  mainframe  processor  must  be  capable  of  providing  an  instruction 
rate  of  500,000  instructions  per  second  to  fulfill  the  interactive  and  batch 
processing  requirement.  Additional  throughput  capability  is  required  in  the 
high-cost  option  to  provide  the  environmental  simulation  for  the  emulation 
processor.  The  processor  must  be  capable  of  supporting  (1)  1.25  Mbytes  of 
main  memory,  (2)  a  very  high-speed  programmable  interface  to  act  as  the 
environmental  simulator  for  the  emulator  processor  in  the  high-cost  option, 

(3)  50  terminals  on  a  50  percent  duty  cycle  at  a  2,400  baud  rate,  and  (4)  up 
to  16  medium-speed  interfaces  to  ISS  processors.  The  processor  architecture 
should  allow  the  attachment  of  multiple-unit  record  devices,  and  it  should 
be  capable  of  attaching  as  many  as  20  disk  drives.  Table  5-1  is  a  represen¬ 
tative  list  of  computer  systems  that  could  fulfill  these  requirements. 

In  the  high-cost  option  of  the  Single-Processor  Architecture,  a  micro- 
programmable  emulation  processor  is  required,  which  would  have  character¬ 
istics  similar  to  the  QM-1  processor  employed  by  WR-ALC-MMEC. 

5. 1.2. 2  Peripherals 

Peripheral  devices  constitute  the  archival  storage,  on-line  mass 
storage,  hard-copy  display,  and  user  terminal  subsystems  include  tape  drive 
units,  magnetic  disk  units,  line  printers,  graphic  plotters,  and  alphanumeric 
and  graphic  CRTs.  The  archival  storage  subsystem  must  provide  at  least  two 
7-track  tape  drives  and  four  9-track  tape  drives.  Whenever  a  dedicated 
tape  unit  is  required  for  off-line  communications  interface,  an  additional 
drive  will  be  required.  The  minimum  set  will  permit  seven  track  applications, 
system  checkpointing  and  journaling,  and  two  concurrent  applications  tape 
mounts,  which  might  restrict  tape  usage  to  one  process  at  a  time. 

The  on-line  mass  storage  subsystem  must  provide  direct-access  storage 
capability  for  up  to  2,000  Mbytes.  For  the  purposes  of  this  study  it  is 
assumed  that  the  storage  media  would  be  magnetic  disk,  requiring  8  to  12 
disk  drives.  However,  it  should  be  noted  that  the  rapid  advances  in  memory 
technology,  particularly  the  development  of  magnetic  bubble  memory,  would 
probably  continue.  Therefore,  this  is  one  area  in  which  technological 
change  might  affect  the  architecture  identified  in  this  study. 


The  hard-copy  display  subsystem  will  provide  centralized  printer  and 
graphic  outputs.  This  capability  would  be  collocated  in  the  support  proces¬ 
sor  facility.  No  remote  print  capability  is  provided  by  this  architecture. 
The  hard-copy  display  subsystem  consists  of  two  high-speed  line  printers 


Figure  5-1.  SINGLE- PROCESSOR  ARCHITECTURE 


1 


Table  5-1.  REPRESENTATIVE  MAINFRAME  COMPUTER  SYSTEMS 

Word 

Maximum 

Manufacturer 

Model 

Length 

Memory 

(Bits) 

(Mbytes) 

Andahl 

470V/5 

64 

8.0 

Control  Data 

Cyber  170 

24 

2.6 

Corporation 

Cray  Research,  Inc. 

Cray-lS 

64 

4.0 

Digital  Equipment 

1060/1070 

32 

4.0 

Corporation 

2040/2060 

32 

3.0 

Honeywell 

Level  66  DPS 

8* 

8.0 

IBM 

3031 

32 

8.0 

3032 

64 

8.0 

Sperry  Univac 

1100/60 

32 

2.0 

1100/80 

32 

4.0 

♦Single  byte  addressability. 

(>1,000  lines  per  minute)  and  one  plotter.  No  requirement  for  punched 
card  or  punched  paper  tape  is  currently  anticipated. 

The  user  terminals  include  a  mix  of  alphanumeric  and  graphics  terminals. 
The  EW  system  would  have  access  to  alphanumeric  terminals,  and  engineering 
management  would  have  access  to  graphics  terminals.  Each  terminal  would 
have  a  standard  ASCII  keyboard.  Graphics  terminals  ("dumb  terminals")  would 
be  equipped  with  a  page-print  device  and  would  have  minimal  formatting  and 
editing  capability.  Buffering,  function  key,  and  character  and  line  editing 
would  also  be  provided. 

5. 1.2. 3  Communications 

The  Single-Processor  Architecture  does  not  employ  a  networking  scheme 
as  such.  In  this  architecture,  interfaces  with  other  processors  are  treated 
as  remote  terminal  interfaces.  Medium-speed  (20  to  50  Kbaud)  processor-to- 
processor  data  links  will  be  provided  for  file  and  software  data  transfer. 
Communications  would  also  be  required  for  user  terminal-to-processor  func¬ 
tions.  This  architecture  would  have  to  support  50  terminals  operating  at 
2,400  baud  on  a  50  percent  duty  cycle.  Communications  with  systems  external 
to  the  EWAISF  would  be  off-line  via  magnetic  tape.  The  system  will  operate 
internally  to  a  single  controlled  area;  therefore,  special  security  features 
(e.g.,  encryption)  will  not  be  required. 
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5. 1.2.4  Software 


The  software  required  to  implement  the  validated  functions  was  described 
in  Chapter  Four.  The  operating  system  requirements  of  this  architecture  are 
characteristically  satisfied  by  those  supplied  with  the  representative  com¬ 
puter  systems  shown  in  Table  5-1.  The  architecture  imposes  no  unusual 
executive  or  control  requirements  on  the  operating  system  or  other  support 
software. 


5.2  MULTIPLE-PROCESSOR  ARCHITECTURE 
5.2.1  Concept 

The  Multiple-Processor  Architecture  is  based  on  a  functionally  distrib¬ 
uted  network  of  minicomputers  having  shared  access  to  peripheral  devices. 

This  architecture  provides  two  high-end  minicomputers  that  support  the  data 
and  computation  functions.  In  the  high-cost  option,  a  separate  emulation 
processor  is  added.  Functions  are  divided  between  the  processors,  which 
are  based  on  the  degree  to  which  they  are  data-handling  oriented  or  compu¬ 
tationally  oriented.  One  of  the  processors  becomes,  in  effect,  a  data 
processing  machine,  and  the  other  processor  becomes  a  scientific  machine. 

The  scientific  machine  serves  as  the  environmental  simulator  for  the  emula¬ 
tion  process  in  the  high-cost  option. 

User  interface  would  be  provided  by  directly  attached,  dedicated 
interactive  terminals.  Terminal  attachment  would  be  divided  between  the 
two  processors.  ISS  processors  would  be  linked  to  the  data  processing 
machine.  Print  files  could  be  transmitted  to  ISS  processors  for  local 
printing. 

Operational  support  of  the  support  processor  would  be  provided  by  a 
support  processor  organization.  Operational  support  of  the  ISS  computer 
systems  would  be  provided  by  the  engineers  assigned  to  the  systems,  which 
reflects  the  current  support  concept. 

Security  aspects  of  this  architecture  are  similar  to  the  Single-Processor 
Architecture  and  include  the  following: 

•  All  support  processor  operations  would  be  centrally  located. 

•  No  terminal  equipments  would  require  interfaces  that  would  exit  the 
controlled  area. 

•  Physical  security  would  be  accomplished  in  the  current  manner. 

•  TEMPEST  requirements  would  be  satisfied  in  the  current  manner. 

Figure  5-2  is  a  block  diagram  of  the  Multiple-Processor  Architecture. 

This  architecture  consists  of  processors,  interactive  terminals,  an  archival 
storage  subsystem,  an  on-line  mass  storage  subsystem,  a  hard-copy  display 
subsystem,  and  associated  communications  and  software. 
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Figure  5-2.  MULTIPLE-PROCESSOR  ARCHITECTURE 


5.2.2  System  Components 


The  components  that  constitute  the  support  processor  subsystems  are 
described  in  the  following  paragraphs. 

5. 2. 2.1  Processors 


The  combined  processors  must  be  capable  of  providing  an  instruction 
rate  of  500,000  instructions  per  second  to  fulfill  the  interactive  and  batch 
processing  requirement.  Additional  throughput  capability  is  required  in  the 
high-cost  option  to  provide  the  environmental  simulation  for  the  emulation 
processor.  Both  the  data-handling  and  computation  processors  should  be 
capable  of  supporting  25  terminals  on  a  50  percent  duty  cycle  at  a  2,400 
baud  rate.  The  data-handling  processor  must  be  able  to  support  up  to  16 
medium-speed  interfaces  to  the  ISS  processors.  The  scientific  machine  must 
be  capable  of  supporting  a  very  high-speed  interface  to  the  emulation  proces 
sor  in  the  high-cost  options.  Each  processor  should  be  capable  of  attaching 
up  to  20  disk  drives  as  well  as  multiple-unit  record  devices.  Table  5-2 
is  a  representative  list  of  computer  systems  capable  of  fulfilling  these 
requirements. 


Table  5-2.  REPRESENTATIVE  HIGH-END  MINICOMPUTER  SYSTEMS 


Manufacturer 

Model 

Word 

Length 

(Bits) 

Maximum 

Memory 

(Mbytes) 

Burroughs  Corporation 

B-1985 

16 

■EB 

B-3950 

16 

H 

Data  General 

ECLIPSE  M/600 

16 

2.0 

ECLIPSE  S/250 

16 

2.0 

ECLIPSE  MV/8000 

32 

2.0 

Digital  Equipment 

PDP  11/70 

16 

2.0 

Corporation 

VAX-11/750 

32 

2.0 

VAX-11/780 

32 

8.0 

Harris  Corporation 

300 

24 

2.0 

Hewlett-Packard  Company 

HP  3000 

16 

4.0 

Honeywell 

Level  6 

16 

1.0 

4.0 

Modular  Computer  Systems 

Classic  7860 

i 

16 

4.0 

Prime  computer,  Inc. 

Series  50 

32 

8.0 

Tandem  Computers 

Non-Stop  System 

16 

32.0* 

*2  Mbytes  per  processor;  up  to  16  processors  per 
configuration. 


In  the  high-cost  option  of  the  Multiple-Processor  Architecture,  a 
microprogrammable  emulation  processor  is  required,  which  would  have 
characteristics  similar  to  the  QM-1  processor  employed  by  WR-ALC/MMEC. 

5. 2. 2. 2  Peripherals 

Peripheral  requirements  for  the  Multiple-Processor  Architecture  are 
the  same  as  those  for  the  Single-Processor  Architecture,  with  the  following 
additional  requirements:  (1)  additional  tape  drive  units  will  be  required  to 
support  the  additional  processor,  and  (2)  all  peripherals  must  be  accessible 
from  multiple  processors,  i.e.,  multiported. 

5. 2. 2. 3  Communications 

Data  communications  for  the  Multiple-Processor  Architecture  are  essen¬ 
tially  the  same  as  those  for  the  Single-Processor  Architecture,  with  the 
following  exceptions:  (1)  a  high-speed  interface  must  be  provided  for 
communications  between  the  data-handling  processor  and  the  scientific 
processor  to  retrieve  data  from  the  support  processor  data  base,  which 
uses  the  services  of  the  data-handling  processor;  and  (2)  both  processors 
require  interfaces  for  terminal  handling. 

In  the  high-cost  option,  the  scientific  processor  will  have  a  high¬ 
speed  interface  to  the  emulation  processor.  The  16  ISS  processor  links 
will  be  terminated  in  the  data-handling  processor.  Again,  communications 
with  external  systems  will  be  off-line  via  magnetic  tape.  The  system  will 
operate  internally  to  a  single  controlled  area,  and  secure,  encrypted 
communications  will  not  be  required. 

5.2. 2.4  Software 


The  software  required  to  implement  the  validated  functions  was  de¬ 
scribed  in  Chapter  Four.  The  operating  system  requirements  of  this 
architecture  are  characteristically  satisfied  by  those  supplied  with  the 
representative  computer  subsystems  identified  in  Table  5-2.  However,  in 
addition  to  the  operating  system  services,  both  the  data-handling  and 
scientific  processors  will  require  terminal  management  software  for  routing 
terminal  task  requests,  user  inputs,  and  processor  outputs.  This  will 
enable  the  terminal  user  to  execute  a  task  in  either  processor,  independent 
of  the  physical  connectivity  of  the  terminal.  Some  software  is  available 
for  computers,  such  as  those  identified  in  Table  5-2,  which  provides  basic 
services  that  permit  the  terminal  management  and  task  routing  algorithms 
to  be  readily  implemented.  Among  these  software  packages  are  Digital 
Equipment  Corporation's  DECNET  and  Hewlett-Packard's  DS/3000. 


5.3  FRONT-END  PROCESSOR  ARCHITECTURE 
5.3.1  Concept 

The  Front-End  Processor  Architecture  is  characterized  by  the  use  of  a 
common  user  interface  for  both  the  ISS  processor  and  the  support  processor. 
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Except  for  the  terminal  functions,  the  Front-End  Processor  Architecture  can 
use  either  the  Single-Processor  or  the  Multiple-Processor  Architectures  as 
a  basis  for  providing  data-handling  and  computation  capabilities.  For  the 
purposes  of  this  study,  it  can  be  assumed  that  the  Multiple-Processor  Archi¬ 
tecture  will  be  used  for  all  services  other  them  terminal -handling  functions. 
In  the  high-cost  option  a  separate  emulation  processor  is  added,  and  the  com¬ 
putation  computer  provides  environmental  simulation.  These  functions  would 
be  established  in  a  support  processor  organization,  which  would  centralize 
support  of  operating  systems  and  software  tools  development. 

The  user  interface  would  be  provided  by  attaching  the  interactive 
terminals  to  front-end  processors,  which  are  then  attached  to  the  ISS  and 
support  processors.  The  front-end  processors  would  provide  a  single-user 
interface  to  the  EWAISF  that  would  be  transparent  to  the  user  with  respect 
to  where  a  particular  function  was  being  performed.  The  front-end  proces¬ 
sors  constitute  a  User  Interface  Subsystem  that  routes  user  task  requests, 
data  inquiries,  and  output  to  and  from  the  appropriate  processor. 

Security  aspects  of  this  architecture  have  one  major  difference  from 
those  of  the  other  architectures.  A  front-end  processor  would  be  located 
on  each  floor,  which  would  permit  attachment  of  local  hard-copy  capability 
on  each  floor.  Print  files  could  also  be  transmitted  to  ISS  processors  for 
local  printing.  This  would  imply  that  the  necessary  control  of  output  and 
security  of  system  operation  would  be  established  in  each  location;  i.e.,  a 
small  computer  operation  would  be  established  on  each  floor.  This  arrange¬ 
ment  has  been  assumed  for  the  Front-End  Processor  Architecture.  Other 
aspects  of  the  architecture  include  the  following: 

•  No  terminal  or  processor  interfaces  would  exit  the  controlled  area. 

•  Physical  security  would  be  performed  in  the  current  manner. 

•  TEMPEST  requirements  would  be  satisfied  in  the  current  manner. 

Figure  5-3  is  a  block  diagram  of  the  Multiple-Processor  Architecture. 
This  architecture  consists  of  processors,  interactive  terminals,  a  User 
Interface  Subsystem,  an  archival  storage  subsystem,  an  on-line  mass  storage 
subsystem,  a  hard-copy  display  subsystem,  and  associated  communications  and 
software.  The  central  processor  shown  in  Figure  5-3  could  consist  of  either 
of  the  processor  configurations  used  in  the  Single-Processor  or  Multiple- 
Processor  Architectures.  For  this  alternative,  the  multiple-processor  con¬ 
figuration  has  been  chosen. 

5.3.2  System  Components 

The  components  that  constitute  the  support  processor  subsystems  are 
described  in  the  following  paragraphs. 


5. 3. 2.1  Processors 

The  central  processor  requirements  of  this  alternative  are  similar  to 
the  Multiple-Processor  Architecture,  with  certain  key  differences.  The 
instruction  rate  for  interactive  and  batch  processing  is  still  500,000 
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instructions  per  second.  Additional  throughput  capability  is  required  in 
the  high-cost  option  to  provide  the  environmental  simulation  for  the  emula¬ 
tion  processor.  However,  since  the  user  terminals  will  be  attached  to  the 
User  Interface  Subsystem,  no  terminal-handling  capability  is  required.  The 
data-handling  machine  must  be  capable  of  terminating  medium-speed  interfaces, 
16  to  the  ISSs  and  4  to  the  User  Interface  Subsystem.  The  scientific  machine 
must  be  able  to  support  a  very  high-speed  interface  to  the  emulation  proces¬ 
sor  in  the  high-cost  options.  Each  processor  should  be  capable  of  attaching 
up  to  20  disk  drives  as  well  as  multiple-unit  record  devices.  Table  5-2 
listed  representative  computer  systems  capable  of  fulfilling  these 
requirements. 

In  the  high-cost  option  of  the  Front-End  Processor  Architecture,  a 
microprogrammable  emulation  processor  is  required,  which  would  have  charac¬ 
teristics  similar  to  the  QM-1. 

The  User  Interface  Subsystem  would  employ  four  small  processors  to  man¬ 
age  terminal  interfaces,  route  tasks  and  data,  and  produce  low-volume  printed 
output.  One  processor  would  be  located  in  the  support  processor  area  and 
the  other  three  are  on  each  floor.  Each  processor  would  be  capable  of  ter¬ 
minating  12  terminals  and  3  medium-speed  interfaces.  The  processor  must  be 
capable  of  attaching  a  printer,  at  least  one  low-volume  disk  drive,  and  a 
tape  or  flexible  disk  drive.  Table  5-3  is  a  representative  list  of  computer 
systems  with  these  characteristics. 


Table  5-3.  REPRESENTATIVE  FRONT 

-END  PROCESSORS 

Word 

Maximum 

Manufacturer 

Model 

Size 

Memory 

(Bits) 

(Kbytes) 

Data  General 

NOVA  3/12 

16 

64 

NOVA  3D 

16 

256 

Digital  Equipment 

PDP  11/34 

16 

124 

Corporation 

PDP  11/35 

16 

124 

Honeywell 

Level  6/33 

16 

64 

IBM 

Series  1/4953 

16 

64 

Series  1/4955 

16 

256 

Wang 

VP /MVP 

8 

256 

VS 

32 

512 
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5. 3.2.2  Peripherals 

Peripheral  requirements  for  the  Front-End  Processor  Architecture  are 
the  same  as  for  the  Multiple-Processor  Architecture,  with  the  following 
exceptions : 

•  Three  additional  low-  to  medium-speed  (400  to  600  lines  per  minute) 
line  printers  are  required  for  the  User  Interface  Subsystem. 

•  Four  magnetic  disk  drives  (5  to  10  Mbytes)  are  required  for  the 
User  Interface  Subsystem. 

•  Four  low-volume  storage  devices  (flexible  disk  or  cassette  tape) 
are  required  for  system  functions. 

•  A  minimal  computer  operator  interface  is  required  for  the  User 
Interface  Subsystem  processors. 

•  Interactive  terminals  in  place  at  the  ISSs  will  be  used  for  all 
functions,  thereby  significantly  reducing  the  terminal  requirements. 

5. 3.2. 3  Communications 

Data  communications  for  the  Front-End  Processor  Architecture  are 
essentially  the  same  as  for  the  Multiple-Processor  Architecture,  with  the 
following  exceptions: 

•  The  interactive  terminals  will  be  terminated  at  the  User  Interface 
Subsystem  processors. 

•  Additional,  medium-speed  interfaces  will  be  required  between  the 
ISS  processors  and  the  User  Interface  Subsystem  processors. 

•  Medium-speed  interfaces  will  be  required  between  the  User  Interface 
Subsystem  processor  and  the  central  processor  scientific  and  data- 
handling  machines. 

Communications  with  external  systems  will  be  off-line  via  magnetic  tape. 

The  system  will  operate  internally  to  a  single  restricted  area, and  secure 
encrypted  communications  will  not  be  required. 

5. 3. 2. 4  Software 

Chapter  Four  described  the  software  required  to  implement  the  validated 
functions.  Operating  systems  for  processors  of  the  types  identified  in 
Table  5-3  vary  significantly  in  terms  of  features  and  support.  An  executive 
routine  will  be  required  to  manage  the  User  Interface  Subsystem  functions. 

The  routing  and  task  management  software  residing  on  the  data-handling  and 
scientific  processors  will  migrate  to  the  User  Interface  Subsystem  processors. 

5 . 4  SUMMARY 

The  three  architectures  to  be  evaluated  in  Phase  4,  Cost-Benefit 
Analysis,  are  the  Single-Processor  Architecture,  Multiple-Processor 
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Architecture,  and  Front-End  Processor  Architecture.  These  architectures 
offer  three  distinct  modes  of  providing  the  EWAISF  support  processor 
functions. 
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CHAPTER  SIX 


COST-BENEFIT  ANALYSIS 


Previous  chapters  have  defined  the  requirements  and  presented  alterna¬ 
tive  architectures  for  the  EWAISF  support  processor.  This  chapter  presents 
estimates  of  costs  and  benefits  for  the  previously  defined  architectures. 


6 . 1  METHODOLOGY 

The  methodology  consists  of  two  parts:  One  part  deals  with  estimated 
costs,  while  the  other  addresses  system  benefits  in  terms  of  the  relative 
performance  of  the  three  alternative  architectures. 

Estimating  costs  is  a  relatively  straightforward  summation  of  expected 
costs  for  each  architecture.  In  each  case,  costs  are  presented  for  devel¬ 
opment,  investment,  and  operation  for  an  assumed  10-year  operating  life. 

As  a  surrogate  for  benefits,  system  performance  is  estimated  for  each 
architecture  using  a  common  workload.  Performance  estimation  is  derived 
from  a  dynamic  simulation  model  developed  for  this  study.  The  performance 
simulation  model  generates  a  job  stream  and  then  "dispatches"  each  job 
through  the  simulated  architecture  on  the  basis  of  the  job's  requirements, 
the  architecture's  capability,  and  the  prior  presence  of  other  jobs. 

Estimates  of  both  costs  and  benefits  should  be  viewed  as  suggestive 
rather  than  definitive.  That  is,  this  analysis  is  intended  to  permit  clear 
rankings  among  alternatives,  without  necessarily  providing  precise  estimates 
of  eitner  cost  or  performance. 


6.2  ARCHITECTURAL  ALTERNATIVES 

The  three  alternative  architectures  analyzed  herein  are  those  defined 
earlier  in  this  report: 

•  Single  mainframe  processor 

•  Multiple  processors 

•  Multiple  processor  with  front-end  processors 


The  essential  elements  of  each  of  these  architectures  are  shown  in  Figure 
6-1.  Also  shown  in  the  figure  is  the  high-cost  option  for  each  architec¬ 
ture,  in  which  an  additional  emulation  processor  has  been  added  to  each 
architecture  for  special  EW  applications.  The  additional  processor  serves 
as  an  EW  system  computer  emulator,  while  the  mainframe  processor,  or  one  of 
the  multiple  processors,  simulates  the  EW  system's  environment  in  near 
real  time. 

The  basic  distinction  between  the  single  mainframe  option  and  the 
multiple-processor  option  is  the  separation  of  CPU  power  and  workload 
into  parallel  job  streams  in  the  multiple-processor  case.  Generally,  jobs 
for  the  EWAISF  support  processor  can  be  characterized  as  emphasizing  either 
computation  or  data  management.  Emulator  jobs  are  characterized  as  an 
especially  intensive  computation  application. 

The  main  distinction  between  the  basic  multiple-processor  option  and 
the  front-end  processor  plus  multiple-processor  option  is  that  the  front- 
end  processor  acts  as  a  dispatcher  to  the  support  processor  and  also  pro¬ 
vides  an  interface  between  terminals  and  ISS  processors. 


6.3  COST  ESTIMATION 

Cost  estimation  for  each  architecture  is  relatively  straightforward. 
However,  difficulties  arise  when  we  attempt  to  derive  and  justify  partic¬ 
ular  estimates  of  individual  cost  components. 

These  cost  estimates  are  not  intended  to  serve  as  a  detailed  fiscal 
blueprint  for  system  acquisition.  Their  purpose  is  to  represent  the  typical 
cost  consequences  of  each  EWAISF  support-processor  option.  The  intent  is 
to  array  the  relative  costs  of  each  option  with  as  much  precision  as  is 
possible  at  this  early  stage.  Thus,  these  cost  estimates,  together  with 
the  accompanying  performance  estimates,  can  indicate  which  option  is  pref¬ 
erable.  Final  cost  estimates  await  specific  decisions  on  such  elements  as 
equipment  and  staffing.  The  current  estimates  are  based  on  apparently 
reasonable  alternatives  of  implementing  the  three  architectures. 

There  are  three  basic  categories  of  cost  elements:  development, 
investment,  and  operation  and  maintenance.  Development  includes  system 
design,  hardware  and  software  development,  and  any  necessary  integration 
and  testing.  Investment  includes  the  cost  of  facilities  to  house  the  sys¬ 
tem;  the  actual  equipment  that  constitutes  the  system;  working  inventory 
of  supplies;  and  auxiliary  charges  for  freight,  installation,  and  initial 
training.  Operation  and  maintenance  include  the  cost  of  labor,  materials, 
maintenance,  and  support  services  required  to  operate  and  use  the  system. 

Discussions  with  cognizant  personnel  reveal  that  several  of  these  cost 
elements  can  be  regarded  as  already  sunk  and  essentially  invariant  with 
respect  to  the  three  options.  These  costs  include  buildings  and  land,  work¬ 
ing  inventory,  materials,  utilities,  and  support  services.  The  following 
sections  present  the  individual  cost  elements;  the  resulting  costs  are  pre¬ 
sented  in  Section  6.3.4. 
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(a)  Single  Mainframe  Architecture 


(b)  Multiple-Processor  Architecture 


(c)  Multiple  Processors  with  Front-End  Processor 


Figure  6-1.  ALTERNATIVE  ARCHITECTURES  FOR  EWAISF  HOST  PROCESSOR 
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6.3.1  Development 

6. 3. 1.1  System  Design 

This  report  constitutes  an  initial  phase  of  system  design  in  that 
requirements  are  defined,  alternative  architectures  derived,  and  compara¬ 
tive  cost  and  performance  estimates  developed.  Study  results  should  allow 
selection  of  a  single  system  architecture  to  be  pursued  in  detail  for  the 
remainder  of  the  system  design  effort,  which  would  involve  detailed  sizing, 
specification  of  performance  characteristics,  verification  and  validation 
of  design,  procurement  preparation,  and  source  selection.  Performing  these 
tasks  will  probably  involve  effort  comparable  to  the  initial  definition  and 
screening  embodied  in  this  report.  Therefore,  the  cost  element  of  system 
design  is  tentatively  estimated  at  $250,000,  regardless  of  the  architecture 
chosen,  and  is  considered  to  take  one  year. 

6. 3. 1.2  Software  Development 

It  is  believed  that  system  hardware  for  any  of  the  alternatives  can 
be  procured  off-the-shelf.  Thus  no  hardware  development  costs  are  foreseen. 
However,  substantial  software  development  costs  are  expected  for  the  three 
architectures.  These  development  ccLits  consist  of  rehosting,  new  develop¬ 
ment,  and  growth  requirements  and  would  be  approximately  the  same  for  each 
architecture.  The  extent  of  these  requirem.  .its  is  outlined  in  Table  6-1. 

In  the  overall  system  timetable  postulated  for  the  cost-benefit  analy¬ 
sis,  it  is  believed  that  both  rehosting  and  new  software  development  will 
occur  during  that  year  in  which  equipment  is  procured,  while  the  growth 
requirement  will  be  met  annually  over  the  next  10  years.  In  all  cases, 
rehosting,  development,  and  growth  are  assumed  to  be  performed  by  technical 
personnel  comparable  to  a  GS-12  rating. 

This  workload  implies  an  initial  force  of  approximately  60  man-years 
to  rehost  and  develop  the  new  software  in  the  first  year  after  procurement, 
with  a  subsequent  reduction  to  17  man-years  per  year  during  the  10-year 
operating  life  of  the  system.  For  comparative  costing,  the  additional  43 
man-years  during  the  installation  year  are  assumed  to  be  obtained  at  a 
cost  approximating  the  1981  salary  of  GS-12  personnel.  (Composite  pay  rates 
for  personnel  are  shown  in  Appendix  C.) 

6.3.2  Investment 


Equipment  cost  estimates  were  obtained  from  a  representative  vendor. 

The  vendor  was  provided  with  the  system  block  diagrams  and  summary  specifi¬ 
cations  outlined  in  Chapter  Five  and  asked  to  submit  a  turnkey  quotation 
for  each  architecture.  These  costs  are  presented  in  Appendix  D. 

Depending  upon  competitive  forces  prevailing  at  the  time  of  procurement 
and  upon  more  detailed  specifications  normally  provided  for  an  actual  pro¬ 
curement,  actual  quotations  might  differ  from  the  informal  quotations  of 
Appendix  D.  However,  for  preliminary  screening,  the  estimates  are  represent¬ 
ative  of  the  previously  defined  architectures,  because  the  vendor  has  no 
known  or  detectable  bias  in  developing  blind  quotations. 
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Table  6-1.  SOFTWARE  DEVELOPMENT  RESOURCES  FOR  THE  EWAISF  SUPPORT  PROCESSOR 


1 - 

Cost  Element 

Lines  of  Code 
(LOC) 

Software  Rehosting* 

158,900 

(Existing  Software) 

Subtotal 

158,900 

New  Software  Development** 

Automatic  Software  Documentation 

3,000 

Data  Reduction/Analysis 

3,000 

V&V  Test  Support 

10,000 

Change  Distribution 

500 

Data  Table  Generation 

500 

ISS  Configuration  Management 

3,000 

Training 

10,000 

Program  Support  Library 

10,000+ 

Project  Control 

10,000+ 

Configuration  Management 

3,000 

Document  Control 

500 

On-Line  Simulation 

10,000 

V&V  Tracking 

500 

System  Modeling 

10,000 

Budget  Cycle  Preparation 

3,000 

Life-Cycle-Cost  Analysis 

3,000 

Procurement  Preparation 

3,000 

Checkbook  Maintenance 

500 

Subtotal 

83,500 

Total 

242,400 

Man-Hours 


52,967 


Man-Years  at 
1,920  Man-Hours/ 
Man-Year 


Growth  Requirement  (10%  per  year) 

=  242,400  LOC  *  (1.1)N_1,  N  =  10 
=  571,566  LOC  (-242,400  at  tQ] 

=  329,116  LOC  growth  at  8  LOC/day 

=  171  man-years 

329,116 

329,116 

171.0 

•Developed  at  24  LOC/day  (including  supporting  data 
* ‘Developed  at  8  LOC/day. 

+Commercially  acquired. 

bases) . 

6.3.3  Operation 


6. 3. 3.1  Labor 


Labor  cost  estimates  are  predicated  upon  the  staffing  as  shown  in 
Table  6-2.  Four  categories  of  staffing  are  envisioned  for  operation  of 
the  EWAISF  support  processor:  management,  operation,  software  development 


■*  I  - 


Table  6-2.  STAFFING  REQUIREMENTS  FOR 
EWAISF  SUPPORT  PROCESSOR 


Function 

Grade 

Number  of 
Personnel* 

Management 

Manager 

GS-14 

1 

Supervisor 

GS-13 

1 

Supervisor 

GS-12 

1 

Secretary 

GS-3/4 

3 

Software  Development 

Software  Developer 

GS-12 

17 

Operation 

Data  Base  Administration 

GS-11 

1 

System  Maintenance 

GS-12 

5 

Librarian 

GS-9 

2 

Shift  Supervisor 

GS-9 

2 

Computer  Operator 

GS-7 

4 

Clerical  (Entry) 

GS-5 

4 

Clerical  (Output) 

GS-5 

2 

EW  Support** 

EW  Support  Personnel 

GS-12 

16  people  at 
1/2  time 

*Based  on  two-shift  operation. 

**Not  required  for  multiple  processor  with  front- 

end  processors. 

and  EW  ISS  support.  For  the  cost-benefit  analysis,  the  software  develop¬ 
ment  labor  is  recorded  under  system  development,  described  in  Section 
6. 3. 1.2,  while  management,  operation,  and  EW  ISS  support  are  recorded 
under  operations.  In  all  cases,  estimated  costs  are  obtained  by  multiply¬ 
ing  the  estimated  required  labor  by  the  appropriate  category  costs  presented 
in  Appendix  C. 


6. 3. 3. 2  Equipment  Maintenance 

Equipment  maintenance  estimates  are  quoted  directly  from  the  vendor 
(see  Appendix  D) .  Although  these  maintenance  estimates  are  subject  to  the 
same  variation  as  the  equipment  quotations  upon  which  they  are  based,  we 
believe  they  fairly  represent  the  three  alternative  architectures. 


Given  the  detailed  estimate  of  system  component  costs,  summary  life¬ 
cycle-cost  profiles  are  presented  in  Tables  6-3,  6-4,  and  6-5.  In  each 
of  these  tables,  system  design  and  installation  and  setup  are  assumed  to 
require  two  years,  and  useful  operating  life  is  10  years.  As  shown  in 
Table  6-5,  the  multiple  processor  with  front-end  processors  is  the  least 
costly  option,  with  present-value  life-cycle  costs  of  $10.2  million  for 
the  basic  systam  and  $10.5  million  for  the  high-cost  option. 

The  multiple  processor  (Table  6-4)  ranks  second  in  life-cycle  costs, 
with  present-value  life-cycle  costs  of  $11.4  million  for  the  basic  system 
and  $11.7  million  for  the  high-cost  option. 

The  single  processor  (Table  6-3)  is  the  most  costly  option,  with 
present-value  life-cycle  costs  of  $12.1  million  for  the  basic  system  and 
$12.4  million  for  the  high-cost  option. 


6.4  BENEFITS  ESTIMATION 

6.4.1  System  Performance  as  System  Benefit 

System  benefits  are  often  defined  and  measured  in  monetary  terms,  such 
as  cost  savings  or  return-on-investment.  However,  in  the  case  of  the  EWAISF 
support  processor,  there  is  no  clear  monetary  measure  of  benefits.  What  is 
of  concern  is  how  well  each  architecture  performs,  what  is  its  level  of 
service,  and  how  capable  is  the  system  in  the  face  of  workload  surges. 
Therefore,  it  seems  most  appropriate  to  use  system  performance  as  the 
measure  of  benefit  to  be  obtained. 

6.4.2  Strategy  for  Estimating  Performance 

The  problem  of  estimating  the  performance  of  hypothetical  systems  in 
treating  a  job  stream  that  does  not  yet  fully  exist  requires  the  following: 

•  Defining  a  job  stream  representative  of  the  expected  workload  to 
be  faced  by  the  EWAISF  support  processor 

•  Defining  basic  performance  capabilities  for  each  architecture 

•  Presenting  the  same  job  stream  to  each  architecture  to  estimate 
that  architecture's  response  and  relative  quality  of  performance 


Therefore,  the  basic  strategy  for  estimating  performance  is  to  simulate 
the  behavior  of  each  architecture  as  it  treats  a  representative  job  stream. 
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.  Present-value  life-cycle  cost  of  basic  system  =  $10,221 
.  Present-value  life-cycle  cost  of  high-cost  option  =  $10,547 

The  standard  table  from  DODI  7041.3  (reproduced  as  Table  C-2  in  Appendix  C)  is  used  for  discounting  to  obtain  present  values 
(at  the  beginning  of  Year  1). 


It  was  initially  believed  that  historical  logs  of  the  existing  system 
would  make  possible  direct  definition  of  a  representative  job  stream  for 
the  new  EWAISF  support  processor.  However,  two  difficulties  were  encountered 

•  It  proved  impossible  to  derive  detailed  job  characteristics  from 
the  summary  data  contained  in  the  system  archives. 

•  It  is  unlikely  that  the  historical  workload  fairly  represents  the 
workload  that  will  confront  the  new  EWAISF  support  processor,  since 
current  workloads  usually  represent  user  adjustment  to  current  sys¬ 
tems.  Such  matters  as  job  size,  timing  of  job  submission,  and  the 
decision  of  whether  to  submit  the  job  at  all  customarily  reflect 
the  expected  quality  of  service. 

Therefore,  the  use  of  historical  data  would  amount  to  testing  the 
ability  of  the  new  architectures  to  cope  with  a  job  stream  that  has  adjusted 
itself  to  the  existing  architecture.  A  job  stream  is  required  that  does 
not  reflect  the  influence  of  this  adjustment. 

It  was  thus  decided  to  generate  a  job  stream  consistent  with  and  based 
on  the  requirements  analysis  phase  of  this  study.  The  typical  or  average 
job  defined  in  Chapter  Four  was  characterized  by  the  following: 

•  5,000  instructions 

•  25  iterations 

•  0.5  of  the  instructions  executed  per  iteration 

•  An  executive  overhead  of  0.25  of  the  program’s  instructions 

•  A  data  storage  requirement  in  main  memory  10  times  the  size  of  the 
program  containing  the  5,000  instructions 

From  these  characteristics,  a  hypothetical  job  stream  was  generated 
by  allowing  each  job  parameter  to  vary  randomly.  The  random  variation  was 
of  the  "minimum  information"  kind,  in  that  each  job  parameter  for  each  job 
was  presumed  to  be  drawn  from  a  uniform  (or  rectangular)  probability  dis¬ 
tribution.  In  this  case,  the  minimum-information  assumption  means  that 
the  maximum  value  of  each  parameter  is  twice  the  mean,  which  gives  the  fol¬ 
lowing  range  for  job  parameters: 

•  1,000  to  10,000  instructions 

•  1  to  50  iterations 

•  0.1  to  1.0  of  the  instructions  executed  per  iteration 

•  0.0  to  0.5  executive  instruction  overhead 

•  1  to  20  as  a  ratio  of  data  to  program  storage  bytes 


Fur  the  special  caae  of  emulation  runs,  the  following  parameters  were 
assumed! 

•  10,000  instructions 

•  1,000  iterations 

•  0.1  executive  instruction  overhead 

•  JO, 000  data  by tea 

Kxercising  the  variability  uf  theae  job  parameters  produces  run  param- 
etera  with  the  following  ranges! 

•  1,000  tu  7 to, 000  executed  instructions 

•  4,000  tu  41)0,000  bytea  uf  main  memory 

•  4,000  tu  40,000,000  bytea  of  1-0  transfer 

The  translation  of  run  parameters  into  run  timea  requires  specifying 
the  performance  capabilities  of  each  architecture.  Three  important  ayatem 
parametera  should  be  specified! 

•  fnat ruction  execution  rate  of  CPU 

•  Capacity  of  main  memory 

•  l-o  transfer  rate  '  .  ween  mass  memory  and  CPU 

On  the  baais  of  the  ayatem  aising  aecompiiahed  during  the  requirements 
analyaia,  the  performance  capabiiitiea  of  the  different  architectures  we»e 
developed,  The  ;ilmjle-P! oceeaor  Architecture  required  the  following! 

•  100,000  instruct  ms  per  aecond  execution  rate 

•  l.ai  megabytes  of  main  memory 

•  1,1  meqabytea  per  aecond  l-t>,  This  la  the  rate  at  which  the  ayatem 
can  aearch  for,  recover,  and  tranamit  data  from  maaa  memory  to  the 
CPU. 

For  the  multiple-processor  option,  these  capabilities  were  partitioned 
between  the  data  applications  processor  and  the  computation  applications 
processor.  The  data  applications  processor  was  characterised  by  the 
following! 

•  a 10, 000  instruct  ions  per  second  execution  rate 

•  O.nai  megabytes  of  main  memory 

•  i . 0  meqabytea  per  aecond  1-0 


ft-ia 
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The  computation  applications  processor  was  characterized  by  the  following: 


•  250,000  instructions  per  second  execution  rate 

•  0.625  megabytes  of  main  memory 

•  0.5  megabytes  per  second  1-0 

For  the  Multiple-Processor  Architecture,  the  partitioning  of  execution 
rate  and  main  memory  was  uniform  between  the  computation  and  data  applica¬ 
tions  processors.  However,  the  data  applications  processor  was  allocated 
twice  the  1-0  capability  of  the  computation  processor,  on  the  basis  that 
data-intensive  work  would  be  passing  more  data  back  and  forth  between  the 
processor  and  mass  memory. 

This  allocation  of  capabilities  is  reasonable  but  not  necessarily 
optimal.  Optimal  allocation  involves  questions  of  detailed  design,  hard¬ 
ware  selection,  and  polling  procedures.  The  present  intent  is  merely  to 
define  typical  capabilities  and  to  estimate  the  resulting  performances  as 
they  relate  to  one  another. 

6.4.2. 3  Performance  Simulation 

In  summary,  performance  simulation  of  the  proposed  EWAISF  architectures 
requires  the  series  of  steps  indicated  below  (these  steps  are  defined  in 
more  detail  in  Appendix  2) : 

•  Develop  functional  descriptions  of  each  architecture.  It  is  apparent 
that  the  crucial  parameters  are  the  instruction  execution  rate 
measured  in  thousands  of  executed  instructions  per  second  (kips) 
and  input-output  rate  of  data  transfer  between  mass  memory  and  CPU 
measured  in  kilobytes  per  second  (kbps) .  It  is  also  true  that  the 
model  makes  no  functional  distinction  (in  terms  of  this  simulation) 
between  the  multiple-processor  option  and  the  multiple  processor 
with  front-end  processors.  This  is  because  the  dispatch  function 
occurs  in  both  options,  and  the  model  does  not  differentiate  between 
which  processor  acts  as  the  dispatcher.  For  an  intensively  used 
communication  net,  this  distinction  could  prove  crucial.  However, 
for  reasonable  job-arrival  rates  for  the  EWAISF  support  processor, 
the  performance  distinction  appears  to  be  trivial.  The  major  dif¬ 
ference  between  these  options  lies  in  cost  differences  generated 

by  different  staffing  requirements. 

•  Generate  a  baseline  job  stream.  Each  job  is  described  by  number 
of  instructions,  number  of  iterations,  number  of  instructions  per 
iteration,  executive  instruction  overhead,  and  data-to-instruction 
byte  ratio.  As  described  above,  each  job's  parameter  is  randomly 
drawn  from  a  rectangular  distribution,  whose  mean  is  the  agreed- 
upon  value  identified  during  the  requirements  analysis. 
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•  Translate  job  parameters  into  run  parameters.  This  is  accomplished 
by  using  the  following  equations: 

••  Executed  instructions  =  (number  of  instructions)  x  (number  of 
iterations)  x  (proportion  of  instructions  per  iteration)  x 
(1.0  plus  executive  instruction  ratio) 

••  1-0  bytes  transfer  =  (number  of  instructions)  x  (2  bytes  per 

instruction)  x  (ratio  of  data  bytes  per  instruction  bytes)  x 
(number  of  iterations)  x  2  (assuming  one  retrieval  and  one 
storage  per  iteration] 

•  Combine  run  parameters  and  architectural  capabilities  to  define  run 
times  for  each  job  for  each  architecture.  This  requires  assigning 
each  job  to  the  appropriate  processor,  computing  1-0  and  execution 
times,  and  then  combining  1-0  and  execution  times  to  yield  a  system 
turnaround  time  excluding  waiting  time. 

•  Present  the  baseline  job  stream  to  each  architecture  at  varying 
arrival  rates.  The  mean  arrival  rates  used  in  this  simulation  are 
75,  150,  300,  and  600  jobs  per  hour.  These  arrival  rates  were 
chosen  as  representative  of  an  EWAISF  support  processor  supporting 
16  EW  systems  and  diverse  management  queries.  These  overall  arrival 
rates  imply  mean  interarrival  times  of  48,  24,  12,  and  6  seconds. 
Following  the  minimum- information  convention  of  generating  job 
characteristics,  these  interarrival  times  are  simulated  by  drawing 
from  rectangular  probability  distributions  ranging  from  0  to  96 
seconds,  0  to  48  seconds,  0  to  24  seconds,  and  0  to  12  seconds. 

As  a  simulation  convention,  one  second  is  treated  as  an  interval  of 
time  in  which  system-processing  events  occur.  A  job  arriving  at  the  system 
is  presumed  to  arrive  at  the  beginning  of  a  simulated  second  and  to  leave, 
thereby  releasing  system  capability,  at  the  end  of  the  second  in  which 
processing  is  terminated. 

6.4.3  Comparative  Simulation  Results 

Table  6-6  summarizes  simulations  of  the  Single  Mainframe  and  Multiple- 
Processor  Architectures.  As  in  the  cost-estimate  case,  it  should  be  stressed 
that  these  simulation  results  can  be  viewed  only  as  indicators  of  relative 
performance;  they  are  not  intended  to  predict  actual  experience. 

The  following  major  conclusions  resulted  from  these  simulations: 

•  Over  a  reasonable  range  of  activity,  all  of  the  system  architectures 
appear  to  be  adequate. 

•  As  the  rate  of  job  submissions  increases,  the  multiple-processor 
option  appears  to  be  more  capable.  All  alternatives  degrade  with 
high  input  rates,  but  the  multiple-processor  alternatives  degrade 
more  gracefully,  i.e.,  more  timely  recovery  from  queues  created  by 
unscheduled  downtime. 
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Table  6-6.  COMPARATIVE  DELAYS  FOR  COMPUTATION  AND  DATA  APPLICATIONS  RUNS 
FOR  THE  SINGLE- PROCESSOR  AND  MULTIPLE-PROCESSOR  ARCHITECTURES 
FOR  VARYING  JOB-ARRIVAL  RATES 


Average  Delay  per 

Job  (In  Seconds) 

Composite  Job 
Arrival  Rate 

Computation 

Data 

Composite  of  | 

Applications 

Applications 

All 

Jobs 

Single 

Multiple 

Single 

Multiple 

Single 

Multiple 

Processor 

Processor 

Processor 

Processor 

Processor 

Processor 

75  per  hour 

2.0 

4.1 

3.0 

1.4 

2.4 

2.8 

150  per  hour 

2.1 

5.7 

5.1 

3.8 

3.5 

4.8 

300  per  hour 

21.8 

32.9 

25.4 

9.4 

23.5 

21.9 

600  per  hour 

112.6 

66.9 

100.4 

63.0 

106.8 

65.1 

I 

1 

I 

I 

I 
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This  assessment  of  system  costs  and  benefits  suggests  that  all  three 
architectures  are  viable  candidates  for  the  EWAISF  support  processor. 

Neither  estimated  costs  nor  performance  simulations  reveal  great  disparities 
among  the  different  alternatives. 

Sufficient  differences  do  exist,  however,  to  establish  a  preference 
ranking  among  the  alternatives.  On  this  basis,  the  multiple  processor 
with  front-end  processors  would  be  the  first  preference.  This  option  is 
the  least  expensive  and  performs  almost  as  well  as  the  single  processor  for 
lig>  workloads  and  significantly  better  for  heavy  workloads.  In  addition, 
th  option  (as  well  as  the  basic  multiple-processor  option)  is  more  capable 
tha  the  single  processor  in  coping  with  heavy  workloads  or  in  dealing'with 
long  queues  resulting  from  unscheduled  outages. 

The  Multiple- Processor  Architecture  is  the  second  preference.  This 
alternative  performs  comparably  to  the  multiple  processor  with  front-end 
processors'  architecture  with  respect  to  simulation  performance.  This 
alternative  does  involve  higher  operating  costs,  which  offsets  the  slightly 
higher  initial  investment  for  the  front-end  processor. 

The  Single-Processor  Architecture  is  the  third  preference.  Although 
apparently  adequate  for  EWAISF  support  processor  requirements,  this  alter¬ 
native  is  the  most  expensive  of  the  three  and  apparently  the  least  capable 
in  dealing  with  heavy  workloads  or  downtime  recovery. 
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CHAPTER  SEVEN 


RECOMMENDATIONS  FOR  IMPLEMENTING  THE 
PREFERRED  ALTERNATIVE 


As  indicated  in  Chapter  Six,  the  multiple  processor  with  front-end 
processors  is  the  preferred  alternative.  This  chapter  presents  a  recom¬ 
mended  approach  to  the  orderly  implementation  of  the  preferred  alternative 
This  approach  takes  into  consideration  the  existing  data-handling  and  com¬ 
putational  facilities  of  the  EWAISF,  as  well  as  planned  near-term  acquisi¬ 
tions.  It  also  considers  the  desire  of  MMR  to  implement  a  more  responsive 
support  capability  as  soon  as  possible. 


7.1  OVERVIEW  OF  APPROACH 


The  recommended  approach  would  implement  the  Front-End  Processor 
Architecture  in  the  1985  time  period.  To  provide  an  interim  capability 
and  to  evolve  expertise  with  networked  architectures,  the  Multiple-Processor 
Architecture  is  implemented  in  the  near  term  as  a  transitional  capability. 
This  implementation  makes  maximum  use  of  existing  resources.  However,  the 
approach  is  predicated  upon  an  orderly  development  cycle  that  will  minimize 
the  potential  negative  impact  on  mission-essential  operation  during  the 
implementation . 

The  approach  would  be  accomplished  in  four  phases,  as  follows: 


•  Phase  1 

•  Phase  2 

•  Phase  3 

•  Phase  4 


Multiple-Processor  Prototype  Development 
Initial  Operation 

Front-End  Processor  Prototype  Development 
Front-End  Processor  Operation 


To  the  greatest  extent  possible,  each  phase  will  utilize  the  equipments 
and  software  of  the  previous  phases.  The  phases  are  defined  in  detail  in 
the  following  sections. 


7.1.1  Phase  1:  Multiple-Processor  Prototype  Development 

The  purpose  of  Phase  1  is  to  implement  and  test  a  support  capability 
that  would  be  available  in  the  near  term.  The  Multiple-Processor  Architec¬ 
ture  is  chosen  for  this  transitional  phase  because  it  is  somewhat  less  com¬ 
plex  to  implement  and  requires  less  augmentation  of  existing  resources  than 


the  Front-End  Processor  Architecture.  This  phase  would  be  accomplished 
by  implementing  a  prototype  Multiple-Processor  Architecture  using  an  aug¬ 
mented  capability  to  be  provided  on  the  EWOLS  and  ECSAS  VAX  11/780  processors. 
On  the  basis  of  the  capabilities  of  the  DECnet  network  processing  architec¬ 
ture,  these  machines  would  be  logically  divided  into  EWOLS  and  ECSAS  and 
computation  and  data-handling  systems.  Figure  7-1  shows  the  logical  divi¬ 
sion  of  these  resources.  The  prototype  would  then  operate  on  only  two 
processors  in  a  "loop  back"  mode;  i.e.,  there  would  be  four  logical  proces¬ 
sors  but  only  two  physical  processors.  Software  development  would  occur 
during  normal  prime-shift  hours,  but  testing  and  operation  would  be  per¬ 
formed  on  a  noninterference  basis  with  mission  operations  of  EWOLS  and 
ECSAS. 

During  this  phase,  some  equipment  augmentation  would  be  required, 
including  the  addition  of  interprocessor  links  between  the  EWOLS  and 
ECSAS  processors  and  the  addition  of  shared  disk  storage  capacity  between 
the  systems.  For  the  prototype  development,  no  change  in  attached  terminal 
assets  would  be  required. 

The  prototype  phase  would  require  the  development  of  the  initial  con¬ 
trol  software  for  the  ISS  processors  and  for  the  support  processors,  i.e., 
the  dispatcher  software.  This  software  would  form  the  basis  for  the  next 
phase  —  Initial  Operations.  The  dispatcher  software,  with  minor  modifica¬ 
tions,  should  be  capable  of  continued  use  throughout  the  subsequent  phases. 

The  steps  necessary  to  accomplish  Phase  1  are  as  follows: 

•  Acquire  and  install  network  links  and  software  (DECnet) 

•  Design  multiple-processor  dispatcher  software 

•  Design  ISS  dispatcher  software 

•  Review  and  prioritize  applications  software 

•  Rehost  critical  software 

•  Design  new  functions 

•  Specify  and  acquire  data  base  management  system  (DBMS) 

•  Specify  and  acquire  document  processor 

•  Implement  dispatcher  software  (support  and  ISS) 

•  Convert  critical  data  bases 

•  Test  and  evaluate  prototype 

The  early  identification  of  critical  software  and  data  bases  for  con¬ 
version  is  imperative  to  provide  an  operational  capability  as  soon  as  pos¬ 
sible.  In  addition,  the  volume  of  EW  system  documentation  residing  and 
being  maintained  on  the  current  support  processor  necessitates  an  early 
start  on  its  conversion.  It  is  recommended  that  only  existing  functions 
be  implemented  during  this  phase.  First,  this  will  permit  more  rapid 


EWOLS  VAX  11/780 


EWOLS 

Functions 


Data-Handling 

Functions 


ISS  Control 
Functions 


Dispatcher 

Functions 


1 

ISS  Control 

t 

Dispatcher 

Functions 

1 

_ i 

Functions 

ECSAS 

— | —  . 
1 

1 

I 

l 

1 

1 

Computation 

Functions 

1 

1 

1 

I 

1 

Functions 

1 

- 1 _ 

ECSAS  VAX  11/780 


Figure  7-1.  LOGICAL  DIVISION  OF 
SYSTEM  RESOURCES 


initiation  of  support  operations.  Second,  the  experience  gained  during 
this  phase  will  provide  for  more  effective  design  of  new  applications. 

Finally,  this  phase  provides  for  a  structured  test  phase.  This  phase 
would  begin  with  nonprime  shift  testing  on  a  noninterference  basis.  This 
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would  include  debug  and  initial  integration  testing.  It  would  then  evolve 
into  an  operational  test  in  which  the  processors  would  perform  EWOLS,  ECSAS, 
and  support  processor  functions  concurrently.  This  latter  testing  is  crucial 
to  the  initiation  of  the  operation  of  the  Multiple-Processor  Architecture  in 
the  EWAISF.  The  initiation  of  operations  without  this  structured  test  phase 
could  jeopardize  ISS  mission  support  operations,  because  of  an  increased 
probability  of  a  support  processor  failure.  Efforts  would  begin  prior  to 
completion  of  Phase  1  test  and  evaluation;  however,  additional  ISSs  would 
not  be  brought  on-line  until  test  and  evaluation  was  complete. 

7.1.2  Phase  2;  Initial  Operation 


During  Phase  2,  the  ISS  processors  would  be  brought  on-line  to  the  sup¬ 
port  processors  (implemented  on  the  EVfOLS  and  ECSAS  processors) .  The  remain¬ 
ing  existing  software  would  be  rehosted,  and  the  new  applications  designed 
in  Phase  1  would  be  implemented.  This  phase  would  result  in  a  cutover  from 
the  existing  U1108  support  processor  to  the  Multiple-Processor  Architecture. 
During  this  phase,  user  training  would  occur,  and  operational  test  and 
evaluation  of  the  support  processor  would  be  accomplished.  The  steps  neces¬ 
sary  for  this  phase  are  as  follows: 

•  Attach  ISS  processors 

•  Install  ISS  dispatcher  software 

•  Implement  new  applications  software 

•  Convert  remaining  existing  applications  software 

•  Convert  remaining  data  bases 

•  Convert  system  documentation 

•  Train  users 

•  Cut  over  from  U1108 

•  Test  and  evaluate  multiple-processor  operations 

At  the  end  of  Phase  2  all  operations  would  be  resident  on  the  new  support 
processor,  and  the  U1108  could  be  removed.  Actually,  the  U1108  could  be 
removed  prior  to  the  end  of  this  phase;  however,  early  elimination  of  the 
U1108  would  result  in  disruption  of  some  existing  capabilities  and  could 
negatively  affect  data  base  and  system  documentation  conversion. 

7.1.3  Phase  3:  Front-End  Processor  Prototype  Development 

During  Phase  3,  a  prototype  would  be  implemented  for  the  Front-End 
Processor  (FEP)  Architecture.  An  architecturally  compatible  ISS  processor 
would  be  selected  for  use  as  a  prototype.  This  processor  would  be  linked 
to  the  support  processor  in  nonprime  time  on  a  noninterference  basis.  The 
executive  software  performing  the  user  interface  would  be  implemented  on 
the  ISS  processor.  Modification  to  the  ISS  and  support  processor  dispatcher 
software  would  be  implemented  as  required.  (It  is  anticipated  that  many  of 
the  changes  required  could  be  implemented  readily  by  changing  the  definition 
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of  the  DECnet  network) .  The  selected  processor  would  be  brought  on-line 
to  the  support  processor,  and  a  test  and  evaluation  would  be  performed. 
The  steps  required  to  accomplish  this  phase  are  as  follows: 


•  Identify  noncompatible  ISS  architectures 

•  Select  FEP  prototype  processor 

•  Design  FEP  software 

•  Design  dispatcher  software  modifications 

•  Implement  FEP  and  dispatcher  software 

•  Attach  FEP  prototype  processor  to  support  processor 

•  Test  and  evaluate  FEP  operations 

•  Analyze  ISS  operating  systems 

•  Develop  special  FEPs  as  required 

As  result  of  the  test  and  evaluation  activity,  sufficient  experience 
will  be  gained  to  ensure  that  all  ISS  processors  with  compatible  architec¬ 
tures  can  be  equalized  in  terms  of  operating  systems  support.  In  those 
cases  in  which  specialized  operating  systems  or  noncompatible  archit 'ctures 
are  necessary,  FEP  software  would  be  tailored  for  that  ISS. 

7.1.4  Phase  4:  Front-End  Processor  Operation 


In  Phase  4  the  preferred  alternative,  described  in  Chapter  Six,  would 
be  implemented  and  would  consist  of  the  following  steps: 

•  Install  FEP  software  on  ISSs 

•  Convert  ISS  and  support  processor  dispatcher  software  as  required 

•  Perform  user  training 

•  Cut  over  from  multiple-processor  operation 

The  installation  and  training  process  would  be  accomplished  on  a  one-system- 
at-a-time  basis  during  nonprime  shift  hours.  Once  installation  and  training 
were  complete,  the  cutover  would  occur  for  all  ISSs  concurrently. 
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7 . 2  SCHEDULE 

The  recommended  schedule  for  implementing  the  described  approach  is 
shown  in  Figure  7-2.  This  schedule  provides  some  capability  in  early  to 
mid-1983  and  the  complete  initial  operating  capability  at  the  end  of  1983. 
Full-system  capability  would  occur  in  mid-  to  late  1985.  This  schedule 
is  predicated  upon  the  personnel  staffing  and  development  resource  estimates 
defined  in  Chapter  Six.  It  provides  for  an  orderly,  controlled  implementa¬ 
tion  of  the  support  processor  capabilities.  On  the  basis  of  these  resource 
estimates,  any  reduction  in  the  schedule  would  require  attendant  additional 
resources  or  a  reduction  in  support  processor  capabilities. 


7-5 


Task 


CY  1982 


CY  1983 
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It  should  be  noted  in  the  schedule  that  achieving  a  full- system  capa¬ 
bility  in  mid-  to  late  1985  requires  project  initiation  in  early  1982. 
Reviews  of  system  capacity  should  be  performed  early  during  each  test  and 
evaluation  step  to  allow  for  augmentation  of  system  resources,  if  required, 
early  in  the  operations  phases. 


7.3  OTHER  CONSIDERATIONS 

The  identified  preferred  alternative  (Front-End  Processor  Architecture) 
and  the  suggested  approach  to  implementing  the  alternative  raise  some  other 
considerations.  First  among  these  is  that  of  EWAISF  organization.  The 
implementation  of  a  networked  structure  within  the  EWAISF  would  argue  for 
a  centralization  of  the  common  support  software  for  the  EWAISF  processors. 
This,  in  fact,  has  recently  occurred  in  WR-ALC/MMR.  However,  the  fact  that 
the  ISS  processors  are  tending  to  standardize  around  the  DEC  architecture, 
coupled  with  the  extent  of  interface  required  with  and  control  assumed  by 
the  FEPs  over  the  ISS  operating  systems,  would  indicate  the  advisability  of 
centralizing  all  nonmission  software  support.  This  would  place  the  support 
of  operating  systems,  as  well  as  common  tools,  in  a  central  support  group, 
facilitating  standardization,  improving  configuration  management  of  support 
resources,  and  assisting  in  development  of  an  experienced  cadre  of  support 
personnel. 

It  may  become  necessary  to  update  the  study  described  in  this  report. 
Circumstances  that  could  require  an  update  include  new  support  concepts  or 
support  of  new  EW  systems.  A  recommended  approach  has  been  prepared  for 
accomplishing  an  update  if  it  is  required.  This  approach  is  described  in 
Appendix  F. 


APPENDIX  A 


USER  REQUIREMENTS  DEFINITION 


This  appendix  presents  the  results  of  the  initial  user  surveys  con¬ 
ducted  in  November  and  December  1980.  A  specification  sheet  was  prepared 
for  each  requirement  identified  by  an  interviewee. 

The  specification  sheet  provides  a  means  for  recording  descriptive 
information,  performance  requirements,  and  operational  considerations  for 
each  identified  requirement.  For  the  preliminary  survey,  no  attempt  was 
made  to  "level"  the  specifications,  i.e.,  interviewee's  requirements  were 
not  interpreted  on  the  basis  of  information  from  another  interviewee.  The 
"leveling"  process  occurred  during  Phase  2,  Requirements  Analysis.  The 
specifications  are  presented  in  the  chronological  sequence  of  the  interviews. 

The  specification  forms  show  the  requirements  anticipated  by  support 
processor  users  for  1985  and  beyond.  Some  of  these  requirements  are 
currently  supported  by  the  UNIVAC  U1108  system  but  others  are  not.  For 
some,  the  support  requirements  change  from  the  present  to  the  study  time 
frame.  The  form  is  divided  into  three  general  fields:  descriptive  infor¬ 
mation,  current  ADP  support,  and  projected  requirements  for  1985  and  beyond. 

The  information  necessary  for  this  phase  of  the  analysis  consisted  of 
the  descriptive  information  to  be  provided  in  the  upper  portion  of  the  form 
and  the  software/functions  portions  of  the  current  support  and  projected 
requirements  sections.  Where  additional  information  was  supplied  by  the 
respondents,  it  has  been  indicated;  otherwise,  the  areas  not  required  have 
been  left  blank. 
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•Prime  support  is  provided  by  VAX  11/780.  Support  processor  can  be  used  as  back-up  only  if  it  is  compatible  with  VAX  11/780. 
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*PrliM  support  is  provided  by  VAX  11/780.  Support  processor  can  be  used  as  back-up  only  if  it  is  compatible  with  VAX  11/780. 


•quirad  ADP  function:  System:  Projected  Life  User /Contact: 

Assembly  EF-111  TJS  Until  replacenent  of  NHRRIC/Hal  Haney  4  Nov  BO 


‘Prime  support  is  provided  by  VAX  11/7B0.  Support  processor  can  be  used  as  back-up  only  if  it  is  compatible  with  VAX  11/780. 


#Pri»e  support  is  provided  by  VAX  11/780.  Support  processor  can  be  used  as  back-up  only  if  it  is  compatible  with  VAX  11/780. 
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Projected  Life:  User/Contact: 

Continuous  MKRRM/Harry  Jennings  5  Nov  80 

Frequency  of  Function: 

This  is  a  continuous  division  support  function. 
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•Binary  tape  device  currently  being  prototyped 
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•A  capability  to  produce  distribution  tapes  on  the  U1108  is  being  prototyped 


"Liaited  ailaatone  capability  available  on  01108 
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•A  binary  tape  output  device  for  AlffOOZN  tapes  is  currently  being  prototyped. 
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'Currently  be: 
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•Workload  projected  to  increase  beyond  shared  support  processor  capability. 
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SP  -  Screening  panel i  CPC SB  -  computer  program  configuration  subboard. 


AW  REQUIREMENTS  SPECIFICATIONS 


•-  yr 


A-66 


ADP  REQUIREMENTS  SPECIFICATIONS 


ADP  REQUIREMENTS  SPECIFICATIONS 


7**fcr*. 


ADP  REQUIREMENTS  SPECIFICATIONS 


ADP  REQUIREMENTS  SPECIFICATIONS 


ADP  REQUIREMENTS  SPECIFICATIONS 


ilgorithm  based  on  usage  data  from  system  accounting  package.  Security  i«  critical 


ADP  REQUIREMENTS  SPECIFICATIONS 


ADP  REQUIREMENTS  SPECIFICATIONS 


ADP  REQUIREMENTS  SPECIFICATIONS 


s  Jj  II 

C  +> 

tli| 


1  i  u  1  M  } 

£  I  I  I  I  I 


If  CRT  notification  is  used,  extensive  terminal  facilities  will  be  required. 
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If  CRT  notification  is  used,  extensive  terminal  facilities  will  be  required. 
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APPENDIX  B 


COMPOSITE  FUNCTIONAL  REQUIREMENTS 


This  appendix  presents  the  composite  definitions  of  EWAISF  Support 
Processor  requirements,  as  described  in  Chapter  Four  and  validated  by  the 
ISS  Support  Subcommittee. 
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Figure  B-l.  TEXT/FILE  EDIT 
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Figure  B-2.  CROSS  COMPILATION  AND  ASSEMBLY 
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Figure  B-5.  DATA  REDUCTION/ANALYSIS 
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Figure  B-6.  VALIDATION  AND  VERIFICATION  (V&V)  TEST  SUPPORT 
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CHANGE  DISTRIBUTION 


SOFTWARE  TOOLS  COMPILATION 
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Figure  B-13.  SOFTWARE  CODE  ANALYSIS 
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Figure  B-16.  PROGRAM  SUPPORT  LIBRARY 
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Figure  B-22.  SYSTEM  MANAGEMENT 
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Figure  B-24.  ON-LINE  SIMULATION 


Figure  B-25.  V&V  TRACKING 
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Figure  B-26.  EMULATION 
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Figure  B-27.  SYSTEM  MODELING 
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Figure  B-28.  BUDGET  PREPARATION 
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Figure  B-31.  CHECKBOOK 
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FINANCIAL  BASIS  FOR  COST  ESTIMATES 


This  appendix  contains  financial  tables  used  to  develop  cost  estimates. 
Table  c-1  presents  the  composite  pay  rates  (as  of  1  October  1980)  used  to 
develop  estimates  of  operation  and  labor  software  development.  Table  C-2 
presents  discount  factors  used  to  obtain  present  values  of  annual  project 
costs.  The  discount  factors  are  based  on  continuous  compounding  of  interest 
at  the  stated  effective  rate  per  annum,  assuming  uniform  cash  flows  through¬ 
out  stated  one-year  periods.  These  factors  are  equivalent  to  an  arithmetic 
average  of  beginning  and  end-of-the-year  compound  amount  factors  found  in 
standard  present-value  tables. 


Table  C-1.  COMPOSITE  PAY 

RATES 

General  Schedule 

1980* 

1981* 

GS-01 

8,281 

9,035 

GS-02 

9,434 

10,292 

GS-03 

10,983 

11,933 

GS-04 

12,701 

13,857 

GS-05 

14,732 

16,073 

GS-06 

16,741 

18,264 

GS-07 

18,184 

19,839 

GS-08 

20,786 

22,678 

GS-09 

22,246 

24,270 

GS-10 

25,195 

27,478 

GS-11 

26,880 

29,326 

GS-12 

32,183 

35,112 

GS-13 

39,066 

42,621 

GS-14 

46,173 

50,375 

GS-15 

53,714 

56,802 

GS-16 

56,802 

56,802 

GS-17 

56,802 

56,802 

GS-18 

56,802 

56,802 

I  ^Executive  limit  to  basic  pay  for  1 

|  employees  is  $50,112.50. 

_ 

Table  C-2. 

PROGRAM/PROJECT 
YEAR  DISCOUNT 
FACTORS 

Project 

Year 

Present  Value 
of  $1  at 

10%  Discount 

1 

0.954 

2 

0.867 

3 

0.788 

4 

0.717 

5 

0.652 

6 

0.592 

7 

0.538 

8 

0.489 

9 

0.445 

10 

0.405 

11 

0.368 

12 

0.334 

13 

0.304 

14 

0.276 

15 

0.251 

16 

0.228 

17 

0.208 

18 

0.189 

19 

0.172 

20 

0.156 

21 

0.142 

22 

0.219 

23 

0.117 

24 

0.107 

25 

0.097 

APPENDIX  D 


PRICE  QUOTATIONS 


Tables  D-l,  D-2,  and  D-3  present  the  representative  price  quotations 
used  to  develop  equipment  cost  estimates  for  the  three  EWAISF  support  proc¬ 
essor  architectures.  These  quotations  form  the  basis  of  the  equipment  cost 
summaries  presented  in  the  cost-benefit  analysis. 

Some  slight  modification  was  necessary  to  make  these  estimates  conform 
comparably  to  both  the  basic  and  enhanced  versions  of  each  architecture. 

For  instance,  the  quotation  received  for  the  single-processor  architecture 
does  not  include  the  emulator  enhancement.  Accordingly,  the  purchase  price 
of  §279,100  and  the  monthly  maintenance  cost  of  $1,372  for  the  emulation 
option  (as  defined  in  Option  2)  were  added  to  the  basic  quotation  of  Option  1 
to  yield  an  estimate  of  the  enhanced  version. 

The  quotation  received  for  the  multiple  processor  includes  the  emulator 
option.  Accordingly,  the  purchase  price  of  $279,100  and  the  monthly  mainte¬ 
nance  cost  of  $1,372  were  deducted  from  the  quotation  to  estimate  equipment 
and  maintenance  costs  of  Option  2.  The  same  procedure  was  applied  to 
Option  3  (multiple  processors  with  front-end  processor) . 


D-l 


Table  D-l.  PRICE  QUOTATIONS  FOR  OPTION  1:  SINGLE 
ARCHITECTURE  (IN  DOLLARS) 

-PROCESSOR 

Quantity 

Monthly 

Equipment  Description 

Maintenance 

Cost 

Price 

Cost 

1 

1091-SC 

KL10-E  CPU 

MCA20  Cache 

2<  RH20 

256  KW  Mos  Memory  (1.25  Megabytes) 

1  RP06  176  MB  Disk  Drive 

LA120 

16  Asynchronous  Lines 

Initial  Support  Package 

2,074 

476,000 

476,000 

2 

RH20  Internal  Channel 

DSMC  @  $34 

68 

15,000 

30,000 

12 

RP06-AA  176  MB  Disk  Drive 

DSMC  @  $250 

3,000 

34,000 

408,000 

1 

TX02-EH  Tape  Controller  and  DX20 
Channel 

595 

96,800 

96,800 

2 

TU71  7  Track  800/1600  BPI  20  IPS 

Tape  Drive 

DSMC  @  $325 

650 

50,000 

100,000 

1 

TU77-CB  Master  800/1600  BPI  125  IPS 
Tape  Drive 

309 

34,800 

34,800 

3 

TU77-AF  9  Track  800/1600  BPI  125  IPS 
Add-On 

DSMC  @  $230 

690 

23,100 

69,300 

2 

LP200-BA  120  LPM  Printer 

DSMC  @  $505 

1,010 

54,000 

108,000 

2 

LP07-YA  64  Character  Band  for  LP200 
Printer 

N/A 

4,300 

8,600 

3 

VT100-DA  16  Pack  VT100-AA  CRT 

368 

25,000 

75,000 

2 

VT100-AA  CRT  Terminals 

DSMC  @  $23 

46 

2,150 

4,300 

50 

BC03M-25,  25-Foot  Null  Modem  Cable 

N/A 

70 

3,500 

1 

QH101-AP  DBMS-10  MT9 ,  800  (includes 

2  training  credits) 

730 

34,500 

34,500 

1 

QH500-XP 

Cobol  68/74  and  SIM,  MT9,  800 

285 

11,500 

11,500 

1 

QH099-XP 

Cobol  68/74  and  SIM,  MT9,  800 

390 

15,000 

15,000 

1 

LXY11  300  LPM  Printer/Plotter  (RS232 
Connection) 

134 

12,600 

12,600 

Total 


10,349 


1,487,900 


Table  D-2.  PRICE  QUOTATIONS  FOR  OPTION  2:  MULTIPLE-PROCESSOR 

ARCHITECTURE  (IN  DOLLARS) 

Quantity 

Equipment  Description 

Monthly 

Maintenance 

Cost 

Purchase 

Price 

Total 

Cost 

1 

SV-AXVCA-CA 

11/760  CPU  2  MB  Memory 

REP07-AA  S12  MB  Disk  and  Controller 
TEU76-AB  1600/6250  125  IPS  Tape  Drive 
H9602-DF  Unibus  Option 

Cabinet 

BA11-KE  Exp  Box  5  SU 

DD11-DK  Two  SU  Backplane 

DZ11-A  8  Line  EIA  Interface 

QE001-AM  VAX/VMS  Operating  System 

1,372 

288,500 

288,500 

2 

SV-AXVCA-CK 

11/780  2  MB  Memory 

REP07-AA  512  MB  Disk  and  Controller 
TEU78-AB  1600/6250  125  IPS  Tape  Drive 
H9602-DF  Unibus  Option 

Cabinet 

BAll-KE  Expansion  Box  5  SU 

DD11-DK  Two  SU  Backplane 

DZ11-A  8  Line  EIA  Interface 

QE001-DZ  VAX/VMS  Operating  System 
License  Only 

BMC  6  SI, 372 

2,744 

279,100 

558,200 

3 

RP07-C 

Dual  Access  Kit 

BMC  8  $20 

60 

5,150 

15,450 

1 

RP07-BA 

RP07  3-Phase  Dual  Access 

BMC  @  $200 

200 

43,140 

43,140 

2 

LP100-BA 

1200  LPM  Character  Band  Printer 

BMC  @  $404 

808 

63,100 

126,200 

2 

LP07-YA 

64/64  Character  Band  for  LP100 

N/A 

4,300 

8,600 

2 

DZ11-B 

8  Line  Expansion 

Multiplexer  for  DZ11-A 

BMC  e  $27 

54 

2,050 

4,100 

4 

DZ11-E 

16  Line  Multiplexer 

BMC  @  $53 

212 

4,300 

17,200 

(continued) 
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Table  D~2.  (continued) 


Quantity 

Equipment  Description 

Monthly 

Maintenance 

Cost 

Purchase 

Price 

Total 

Cost 

3 

FP780-AA 

Floating  Point  Accelerator  11/780 

BMC  @  $48 

144 

10,600 

31,800 

1 

TU78-AB 

1600/6250  Tape 

BMC  @  $170 

170 

25,500 

25,500 

4 

TM78-C 

Dual  Access  Kit  for  TU78  Tape  Drive 

BMC  @  $20 

80 

5,150 

20,600 

3 

VT100-DA 

Pack  of  16  VT100-AA 

BMC  @  $288 

864 

25,000 

75,000 

2 

VT100-AA 

BMC  @  $18 

36 

2,150 

4,300 

50 

BC03M-25,  25-Foot  Null  Modem  Cables 

N/C 

70 

3,500 

1 

QE1 00-AY 

VAX- 11  Fortran 

40 

8,050 

8,050 

1 

QE099-AY 

VAX-11  Cobol 

40 

13,800 

13,800 

2 

QE100-DZ 

VAX-11  Fortran  License  Only 

N/A 

4,490 

8,980 

2 

QE099-DZ 

VAX-11  Cobol  License  Only 

N/A 

7,590 

15,180 

3 

PCL11-B 

Multiple  CPU  Link 

BMC  @  $63 

189 

7,750 

23,250 

Total 


7,013 


1,291,350 


Table  D-3.  OPTION  3:  PRICE  QUOTATIONS  POR  FRONT-BID/ 

MULTIPLE  PROCESSOR  ARCHITECTURE  (IN  DOLLARS) 

Quantity 

Equipment  Description 

Monthly 

Maintenance 

Cost 

Purchase 

Price 

Total 

Cost 

1 

EV— AXVCA-CA 

11/780  CPU  2  MB  Memory 

RBP07-AA  512  MB  Disk  and  Controller 
TEU78-AB  1600/6250  BPI  125  IPS  Tape 
Drive 

H9602-DF  Unibus  Option 

Cabinet 

BA11-KE  Expansion  Box  5  SU 

DD11-DK  Two  SU  Backplane 

D211-A  8  Line  EIA  Interface 

QE001-AM  VAX/VMS  Operating  System 

1,372 

288,500 

288,500 

2 

SV-AXVCA-CK 

11/780  2  MB  Memory 

RFP07-AA  512  MB  Disk  and  Controller 
TEU78-AB  1600/6250  125  IPS  Tape  Drive 
H9602-DF  Unibus  Option 

Cabinet 

BA11-KE  Expansion  Box  5  SU 

DD11-DK  Two  SU  Backplane 

D211-A  8  Line  EIA  Interface 

QE001-DZ  License  Only  VAX/VMS 

BMC  8  $1,372 

2,744 

279,100 

558,200 

1 

SM-40MMA-CA 

11/44  CPU  256  KB  Mos  Memory 

H9642  Cabinet  with  Dual  TU58 

RL211-AK  10  MB  Disk  and  Controller 

LAI 20  DECwriter  Console  Terminal 
RL02-AK  10M  Disk 

QJ738  RSX-11M 

302 

52,000 

52,000 

3 

SM-40MMA-CK 

11/44  CPU  256  KB  Mos  Memory 

H9642  CAB  with  Dual  TU58 

RL211-AK  10  MB  Disk  and  Controller 
LA120  DECwriter  Console  Terminal 
RL02-AK  10M  Disk 

Q5738  RSX-11M  License  Only 

BMC  8  $302 

906 

47,000 

141,000 

4 

DZ11-E 

16  Line  Multiplexer  (EIA) 

BMC  8  $27 

108 

4,300 

17,200 

3 

VT100— DA 

Pack  of  16  VT100-AA 

BMC  8  $288 

864 

25,000 

75,000 

48 

BC03M-25,  25-Foot  Mull  Modem  Cable 

M/C 

70 

3,360 

3  RP07  60  5,150  15,450 

Dual  AcceBS  Kit 
BMC  8  $20 


Table  D-3.  (continued) 

Quantity 

Equipment  Description 

Monthly 

Maintenance 

Cost 

Purchase 

Price 

Total 

Cost 

1 

RP07-BA 

Dual-Access  3-Phase  512  MB  Formatted 
Disk  Drive 

200 

43,140 

43,140 

2 

LP100-BA 

1200  LPM  Character  Band 

BMC  @  $404 

808 

63,100 

126,200 

2 

LP07-YA 

64/64  Character  Band  for  LP100 

Printer 

N/A 

4,300 

8,600 

3 

FP780-AA 

Floating  Point  Accelerator  11/780 

BMC  @  $48 

144 

10/600 

31,800 

1 

TU78-AF 

1600/6250  BPI  Tape  Drive 

170 

25,500 

25,500 

4 

TM78-C 

TU78  Dual  Access  Kit 

BMC  @  $20 

80 

5,150 

20,600 

3 

LXY11-AD 

300  LPM  Printer/Plotter 

BMC  @  $134 

402 

12/600 

37,800 

10 

DMF11-AC 

56  KB  -  1  MB  Local  Link 

BMC  @  $37 

370 

4,200 

42,000 

5 

DD11-DK 

2  Quad  7  Hex  Backplane 

N/C 

900 

4,500 

6 

BC55M-98 

98  FR  Triax  Amp  DMR11  Local 

N/C 

155 

930 

1 

QE100-AY 

VAX- 11  Fortran 

40 

8,050 

8,050 

2 

QE100  D2 

VAX-11  Fortran  License  Only 

N/A 

4,490 

8,980 

1 

QE099-AY 

VAX-11  Cobol 

40 

13,800 

13,800 

2 

QE099-D2 

VAX-11  Cobol  License  Only 

N/A 

7,590 

15,180 

Total 

8,610 

1,537,790 
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APPENDIX  E 


PERFORMANCE  SIMULATION 


The  system  performance  results  reported  in  Chapter  Six  are  based  on  a 
simulation  model  developed  for  this  study.  This  appendix  describes  the 
logic  and  operation  of  the  performance  simulator  summarized  in  the 
report. 

MODEL  OVERVIEW 

Figure  E-l  is  an  overall  schematic  for  the  performance  simulator,  which 
shows  that  performance  simulation  consists  of  four  major  activities: 

•  Define  job  parameters 

•  Define  run  parameters 

•  Calculate  run  requirements 

•  Present  the  job  stream  to  the  system 

This  sequence  of  activities  applies  to  each  individual  job  and  also  to 
the  simulation  as  a  whole.  In  both  cases,  simulation  begins  by  defining  job 
parameters,  e.g.,  instructions,  number  of  iterations.  The  next  step  is  to 
convert  these  job  characteristics  into  run  parameters,  which  define  the 
actual  workload  for  the  processor. 

Given  the  run  parameters  for  a  job,  the  next  step  is  to  calculate  run 
requirements,  accomplished  by  combining  run  parameters  (e.g.,  number  of 
executed  instructions)  with  the  processor's  capabilities,  such  as  instruc¬ 
tion  execution  rate.  These  calculations  yield  the  execution  time,  1-0 
time,  and  main  memory  requirement  for  each  job.  The  final  step  of  the 
simulation  is  to  present  the  job  or  job  stream  to  the  simulated  processor 
and  compute  the  results. 

Each  of  these  major  elements  of  performance  simulations  consists  of 
a  series  of  detailed  definitions,  rules,  and  calculations.  The  nature  of 
these  details  and  their  implementation  in  the  performance  simulator  are 
discussed  in  the  following  paragraphs. 
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Define  Job  Parameters 


A  =  number  of  instructions 
B  =  number  of  iterations 

C  =  proportion  of  instructions  executed  per  iteration 
D  =  executive  instruction  overhead  (ratio  of  executive  instruc¬ 
tions  to  written  program  instructions ) 

E  =  ratio  of  data  bytes  to  program  instruction  bytes 


Define  Run  Parameters 


Executed  instructions  =  A  *  B  *  C  *  (D+l) 
Main  memory  requirements  =  2A(1  +  E) 
Input-output  bytes  =4*a*B*e 


Calculate  Run  Requirements 


If  a  multiple-processor  simulation,  use  expected  1-0 
requirements  to  select  which  processor  will  serve  the  job 
Tally  main  memory  requirements  from  run  parameters  above 
Calculate  execution  time  =  (A  x  B  x  C  *  D) / (processor ' s 
instruction  execution  rate) 

Calculate  1-0  time  =  (4  x  A  x  B  x  E) / (processor ' s  1-0  rate) 
Calculate  total  run  time  *  execution  time  +  1-0  time 


Present  Job  Stream  to  System 


Select  average  arrival  rate 

Calculate  distribution  of  interarrival  times 
Select  arrival  times  for  first  and  successive  jobs 
Begin  to  execute  each  job  upon  arrival  or  after  previous 
jobs  have  cleared  the  processor 

Each  job  occupies  the  processor  during  the  job's  entire 
run  time  (execution  time  +  1-0  time) 

For  each  job,  tally  the  arrival,  waiting,  start,  and 
finish  times 


Figure  E-l.  GENERAL  SCHEMATIC  FOR  PERFORMANCE  SIMULATION 


DEFINE  JOB  PARAMETERS 


The  job  parameters  chosen  to  describe  each  job  were  selected  because 
they  are  the  fundamental  characteristics  that  determine  computer  resource 
requirements.  They  are  also  the  parameters  used  for  architectural  sizing 


in  the  requirements  analysis.  There  are  five  basic  job  parameters  of 
concerns 


•  Number  of  instructions 

•  Number  of  iterations 

•  Proportion  of  instructions  executed  per  iteration 

•  Executive  instruction  overhead  (ratio  of  executive  instructions  to 
written  program  instructions) 

•  Ratio  of  data  bytes  to  program  instruction  bytes 

During  the  requirements  analysis,  typical  values  for  these  parameters 
were  developed,  validated,  and  then  used  for  architecture  sizing.  These 
typical  or  average  values  were  as  follows: 

•  5,000  instructions 

•  25  iterations 

•  0.5  (50  percent)  of  instructions  executed  per  iteration 

•  0.25  executive  instruction  overhead 

•  10  data  bytes  per  program  byte 

Although  these  parameter  values  may,  in  fact,  typify  the  future  job 
stream,  we  cannot  reasonably  expect  all  jobs  to  be  identical.  It  is  also 
possible  that  future  job  streams  may  drift  or  depart  from  these  averages. 
Therefore,  the  simulation  permits  variation  around  these  averages. 

This  variation  is  introduced  into  the  performance  simulator  by  making 
what  is  called  a  "minimum  information"  assumption.  That  is,  in  the  absence 
of  other  information,  it  is  assumed  that  each  outcome  of  each  parameter  is 
equally  likely.  This  assumption  leads  to  two  results: 

•  Each  value  of  each  parameter  for  each  job  in  the  simulation  is 
drawn  from  a  uniform  (or  rectangular)  probability  distribution. 

•  The  maximum  value  of  each  parameter  is  twice  its  average. 

Thus,  after  truncating  slightly  at  the  lower  end  to  avoid  trivial  jobs, 
the  following  parameter  ranges  result: 

•  1,000  to  10,000  instructions 

•  1  to  50  iterations 

•  0.1  to  1.0  of  instructions  executed  per  iteration 

•  0.0  to  0.5  executive  instruction  overhead 

•  1  to  20  data  bytes  per  program  instruction  byte 

These  are  the  parameter-value  ranges  from  within  which  values  are  chosen 
randomly  to  define  job  parameters  for  each  job  in  the  simulation. 
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There  is  one  exception  to  this  general  method  of  generating  job  param¬ 
eters.  The  exception  concerns  emulation  runs,  which  are  generated  separately 
as  intensive  computation  applications.  Emulation  job  characteristics  assumed 
for  this  performance  simulation  are  as  follows: 

•  10,000  instructions 

•  1,000  iterations 

•  1.0  (100  percent)  of  instructions  executed  per  iteration 

•  0.5  executive  instruction  overhead 

•  1  data  byte  per  program  instruction  byte 

DEFINE  RUN  PARAMETERS 

The  next  major  step  in  performance  simulation  is  to  translate  job 
parameters  into  run  parameters:  executed  instructions,  main  memory  require¬ 
ments,  and  1-0  bytes.  This  translation  is  accomplished  by  the  following 
formulas: 

Executed  instructions  =  (number  of  instructions)  *  (number  of 

iterations)  *  (proportion  of  instructions 
executed  per  iteration)  x  (1  +  executive 
instruction  overhead  ratio) 

Main  memory  =  2  x  (number  of  instructions)  x  (1  +  ratio 

requirements  of  data  bytes  to  program  instruction  bytes) 

Input-output  bytes  =  4  x  (number  of  instructions)  x  (number  of 

iterations)  x  (ratio  of  data  bytes  to  program 
instruction  bytes) 

The  formula  for  executed  instructions  is  self-explanatory.  However, 
some  assumptions  require  explanation  regarding  the  derivations  of  main 
memory  requirements  and  input-output  bytes. 

Main  memory  requirements  are  driven  primarily  by  the  number  of  instruc¬ 
tions  and  the  ratio  of  data  bytes  to  program- instruction  bytes.  It  is 
assumed  that  each  instruction  requires  2  bytes  of  main  memory.  This 
value  is  chosen  as  being  representative  of  the  various  processors  suitable 
for  this  application  and  is  the  source  of  the  "2"  in  the  main  memory 
requirement  equation. 

Input-output  bytes  refer  to  the  total  number  of  data  bytes  transferred 
between  mass  memory  and  the  processor  during  program  execution.  It  is 
assumed  that  this  transfer  occurs  twice  during  each  iteration.  At  the  start 
of  the  iteration,  transfer  occurs  from  mass  memory  to  the  processor;  at  the 
end  of  the  iteration,  the  processor  returns  the  processed  data  to  mass 
memory. 
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The  single  exception  to  this  input-output  calculation  occurs  for  emula¬ 
tion  runs,  which  are  viewed  as  being  especially  computation-intensive.  This 
focus  is  reflected  in  a  reduced  input-output  data  flow.  Specifically,  one 
transfer  is  assumed  to  occur  at  the  start  from  mass  memory  to  processor, 
and  another  transfer  from  processor  to  mass  memory  is  assumed  at  the  end 
of  the  run.  Intervening  iterations  rely  solely  on  the  results  of  the 
previous  calculations. 

CALCULATING  RUN  REQUIREMENTS 

The  performance  simulator  determines  three  major  run  requirements: 
main  memory  bytes,  execution  time,  and  1-0  time. 

Main  memory  requirements  are  simply  carried  over  intact  from  the  above 
run  parameter  calculations.  For  these  simulations,  main  memory  proves  not 
to  be  a  governing  constraint,  given  the  job  parameters  and  processor  param¬ 
eters.  Therefore,  the  main  memory  requirement  is  not  treated  further. 

Execution  time  is  calculated  by  dividing  the  number  of  executed  instruc¬ 
tions  by  the  instruction  execution  rate  for  the  processor.  1-0  time  is 
calculated  by  dividing  the  total  1-0  bytes  by  the  1-0  transfer  rate.  Total 
run  time  is  the  sum  of  execution  time  and  1-0  time. 


The  processor  rates  used  for  these  simulations  are  as  follows: 


System 


Instruction 

Execution 

Rate 


1-0 

Transfer 

Rate 


Single  processor 
Computation  processor 
Data  processor 


500  kips* 
250  kips 
250  kips 


1,500  kbps** 
500  kbps 
1,000  kbps 


The  overall  execution  and  1-0  rates  were  chosen  as  representing  the 
capability  envisioned  in  the  requirements  analysis  portion  of  this  study. 
For  the  multiple-processor  option,  this  capability  was,  as  a  first  approxi¬ 
mation,  simply  divided  between  the  processors.  Detailed  design  might  pro¬ 
vide  more  refined  or,  possibly,  dynamic  allocations  of  this  capability. 


PRESENTING  THE  JOB  STREAM  TO  THE  SYSTEM 


The  preceding  steps  of  the  performance  simulation  generate  basic  job 
parameters,  translate  the  job  parameters  to  run  parameters,  calculate  run 
requirements,  and  finally  yield  an  overall  run  time  for  each  run. 


*kips  =  thousands  of  instructions  per  second. 
**kbps  =  kilobytes  per  second. 
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The  next  major  step  of  the  simulation  is  to  present  the  job  stream  to 
the  system  and  then  compute  system  performance.  This  part  of  the  simulation 
consists  of  the  following  actions; 

•  Select  average  arrival  rate 

•  Calculate  distribution  of  interarrival  times 

•  Select  arrival  times  for  first  and  successive  jobs 

•  Begin  to  execute  each  job  upon  arrival  or  as  soon  as  the  previous 
job  is  completed 

•  For  each  job,  tally  the  arrival,  waiting,  start,  and  finish  times 

The  average  arrival  rates  chosen  for  these  simulations  are  75,  150,  300, 
and  600  jobs  per  hour.  These  rates  are  chosen  to  bracket  somewhere  within 
them  the  actual  future  job  stream.  The  upper  end  of  the  range  is  selected 
to  reflect  heavy  workloads  during  recovery  from  downtime.  An  average 
arrival  rate  of  75  jobs  per  hour  translates  to  an  average  incerarrival 
time  of  48  seconds;  150  jobs  per  hour  to  24  seconds,  300  jobs  per  hour  to 
12  seconds,  and  600  jobs  per  hour  to  6  seconds. 

The  generation  of  actual  arrival  times  from  these  averages  follows 
the  same  minimum  information  procedure  used  to  develop  job  parameters. 

Thus  a  mean  interarrival  time  of  48  seconds  implies  that  actual  inter¬ 
arrival  times  were  generated  randomly,  with  each  interarrival  time  being 
added  to  the  arrival  time  of  the  preceding  job. 

As  a  simulation  convention,  a  second  is  an  interval  of  time  in  which 
events  occur.  By  convention,  a  job  is  presumed  to  arrive  at  the  processor 
at  the  beginning  of  a  simulated  second.  A  job  leaves  the  processor  at  the 
end  of  a  simulated  second  and  entirely  occupies  the  processor  while  exe¬ 
cuting.  Therefore,  the  overall  run  times  previously  calculated  are  rounded 
up  to  the  next  whole  second. 

Data  applications  are  distinguished  from  computation  applications  on 
the  basis  of  factors  governing  1-0  requirements.  Aside  from  number  of 
instructions,  the  main  factors  are  number  of  iterations  and  the  ratio  of 
data  bytes  to  instruction  bytes.  It  is  the  product  of  these  factors  that 
determines  a  job's  1-0  bytes. 

Accordingly,  a  job  is  judged  to  be  a  data  application  or  computation 
application  on  the  basis  of  the  product  of  its  number  of  iterations  and 
ratio  of  data  bytes  to  program  instruction  bytes.  This  product  is  com¬ 
pared  with  the  product  of  average  values  of  these  parameters.  An  average 
of  25  iterations  and  10  data  bytes  per  program  instruction  byte  is  expected. 
Therefore,  250  is  the  threshold  value  used  to  distinguish  between  data  and 
computation  applications.  Jobs  whose  product  exceeds  250  are  considered  to 
be  data  applications,  while  jobs  whose  product  is  up  to  and  including  250 
are  computation  applications.  The  sole  exception  to  this  rule  is  an  emula¬ 
tion  run,  whose  product  is  1,000  but  is  always  treated  as  a  computation 
application. 
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The  above  procedur  s  create  a  simulated  job  stream  find  then  simulate 
the  serving  of  this  job  stream  by  the  modeled  architecture.  The  quality 
of  this  simulated  service  is  measured  by  the  average  delay  per  job. 

For  reporting  summaries  of  delays,  the  simulated  jobs  are  treated  as 
groups,  such  as  "composite  job  stream  arriving  at  a  rate  of  75  per  hour 
and  executed  on  the  single  processor."  For  each  such  group,  average  delay 
is  calculated  by 


Average  delay  = 


Sum  of  de^^ys  for  all  jobs  in  group 
Number  of  jobs  in  the  group 


It  is  these  average  delays  that  are  reported  in  Chapter  Six,  Table 
6-6.  Comparisons  among  these  delays  are  used  to  assess  the  relative  per¬ 
formances  of  alternative  architectures. 


E-7 


APPENDIX  F 


STUDY  UPDATE  PROCEDURE 


INTRODUCTION 

For  a  variety  of  reasons  it  may  become  necessary  to  update,  revise, 
or  extend  the  study  described  in  this  report.  Likely  reasons  for  updating 
include  support  of  new  EW  systems,  introduction  of  new  support  functions 
and  new  support  concepts,  or  some  combination  of  these  events. 

Regardless  of  the  cause,  a  standard  update  procedure  should  be  used 
to  estimate  the  impact  of  new  requirements.  This  procedure  consists  of 
five  basic  steps: 

•  Define  new  requirement 

•  Validate  requirement 

•  Estimate  hardware  and  software  impact 

«  Estimate  required  changes  to  system  architecture  configuration 

•  Revise  cost-benefit  analysis 

These  five  steps  are  summarized  in  the  following  sections. 

DEFINE  NEW  REQUIREMENT 

The  new  requirement  must  be  defined  in  sufficient  detail  that  it  can 
be  reviewed,  approved,  and  used  to  develop  quantitative  estimates  of  effects 
on  system  configuration,  costs,  and  benefits.  That  is,  requirement  defini¬ 
tion  must  lead  to  measurable  results.  Sample  hypothetical  new  requirements 
include: 


1  •  New  reports  or  kinds  of  analyses  for  existing  EW  systems 

•  New  EW  systems  to  be  supported 

1  The  requirement  should  be  specified  in  all  particulars,  as  defined  in 

Chapter  Three  (Figure  3-1,  Sample  ADP  Requirements  Specification  Form). 

i 
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VALIDATE  NEW  REQUIREMENT 


Following  definition,  a  new  requirement  requires  validation  by  the  ISS 
community.  Generally,  this  requires  a  series  of  interviews  with  representa¬ 
tives  of  each  ISS  to  assure  that  the  new  requirement  is  completely  and 
consistently  defined.  This  survey  should  review  the  general  nature  of  the 
requirement,  its  overall  size  and  general  technical  thrust,  expected  fre¬ 
quency  of  usage,  and  possibly  its  relation  to  existing  requirements.  The 
result  of  thisi  review  is  a  composite  requirement  specification,  as  defined 
in  Chapter  Four.  This  specification  is  then  presented  to  cognizant  manage¬ 
ment  for  validation. 

HARDWARE  AND  SOFTWARE  IMPACT 

After  a  new  requirement  has  been  defined  and  validated,  the  definition 
must  be  expressed  in  terms  of  ADP  hardware  and  software  resources.  This 
means  that  the  requirement  must  be  translated  into  system  usage  terms  such 
as: 

•  Size,  form,  and  frequency  of  system  inputs,  e.g. ,  data,  analysis 
routines,  and  assorted  queries 

•  Expected  frequency,  method  of  submission,  and  required  turnaround 
for  runs 

•  Special  requirements  for  computation  or  peripheral  devices 

•  Additional  new  code  required  to  install  the  new  requirement  and 
provide  for  anticipated  growth 

•  Expected  usage  of  existing  resources  and  any  modification  or  exten¬ 
sion  required  for  such  usage 

SYSTEM  ARCHITECTURE  CHANGES 

At  this  point,  it  is  necessary  to  review  the  existing  system  architec¬ 
ture  to  see  whether  the  new  requirement  implies  a  growth  of  capacity,  recon¬ 
figuration,  or  change  in  operating  philosophy.  Unless  the  impact  is  self- 
evident,  the  best  procedure  is  to  introduce  the  new  requirement  as  a  tenta¬ 
tive  increment  to  the  existing  system  workload  and  block  diagram  schematic. 
The  impact  of  these  increments  can  then  be  traced  by  using  the  cost-benefit 
methodology  described  in  the  following  section. 

COST-BENEFIT  ANALYSIS 

Updating  the  cost-benefit  analysis  consists  of  two  major  tasks.  The 
first  task  is  to  estimate  the  incremental  system  costs  resulting  from  the 
new  requirement.  These  costs  will  appear  as  growth  factors  in  either  or 
both  of  the  following  basic  categories: 

•  Investment  for  new  hardware  and  development  of  new  software 

•  Operation  and  maintenance  (primarily  new  staffing)  to  satisfy  the 
new  requirement 
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As  before,  system  benefits  are  viewed  in  terms  of  system  performance: 
how  well  a  configuration  serves  the  expected  workload.  In  practice  this 
means  repeating  the  system  simulation  as  described  in  Appendix  E.  The 
basic  steps  are  as  follows: 

•  Define  the  incremental  job  stream  resulting  from  the  new  requirement 

•  Add  the  incremental  job  stream  to  the  baseline  job  stream 

•  Define  architecture  variants  of  the  original  schematic 

•  Present  the  augmented  job  stream  to  the  original  architecture  and 
to  the  tentatively  defined  variants 

•  Compute  system  performance  for  bas®)if.e  and  augmented  workloads  for 
baseline  and  augmented  architect’*  * 

The  last  step  is  of  particular  inter**-*  *  r;e  the  new  workload  may  inter¬ 
fere  with  the  baseline  service. 

MANAGEMENT  DECISION 

The  results  of  this  analysis  are  then  presented  to  the  appropriate 
management  authority  for  an  implementation  decision.  If  the  decision  is 
made  to  implement  the  requirement,  the  augmented  workload  and  resulting  new 
architecture  (if  any)  become  the  baseline  for  further  analyses. 
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